- 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