- From: Rottsches, Dominik <dominik.rottsches@intel.com>
- Date: Wed, 15 Jan 2014 15:41:02 +0000
- To: "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi Anton, On 09 Jan 2014, at 22:57, Anton Vayvod <avayvod@google.com> wrote: >> However, could you explain a little more what this URL here represents: >> Is this the same URL as in requestShow, i.e. a "remote screen app" page >> ___location href? Or is this URL more used in the sense of an application >> or organization identifier and does not actually point to a document? > We thought of this as the same URL as in requestShow to make things simpler - the developer only needs to think about one exact URL - and more Chromecast-agnostic since it's not some proprietary application id. We felt that allowing some custom URI schemes like cast://applicationId instead of the URL would be too specific to Cast protocol only. How about the case when navigation occurs in the secondary page�s context? Do we need to prohibit that? Or do we just record the initial �requestShow� parameter URL for re-discovering existing sessions? I am thinking about a case where the secondary page navigates away from the initial URL by manipulating document.___location.href, for example. Dominik
Received on Wednesday, 15 January 2014 15:41:38 UTC