Re: Presentation API changes proposal

Hi Dominik,

I think we need to guarantee that if the URL is the same the web site is
guaranteed to rejoin the existing session. Prohibiting the navigation is
probably the right way to achieve this.

It could prevent some use cases like CDN or redirects based on the second
UA/display properties or modifying the URL query but I believe all these
use cases could be handled without navigation as well. While navigating the
user to a web site that doesn't act as a receiver could become a
frustrating experience.

Thanks,
Anton.


On Wed, Jan 15, 2014 at 3:41 PM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> 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
>