Re: Google/Mozilla Presentation API update

On Tue, Aug 19, 2014 at 1:07 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi Jonas, MarkF, All,
>
> On 16 Aug 2014, at 01:00, Jonas Sicking <jonas@sicking.cc> wrote:
>
> > This is not entirely accurate. The point of "onlyReconnect" is that
> > when set to true, the UA *never* needs to get user consent.
> >
> > If the page is already running, and the session id is matching, then
> > clearly the user has given consent in the past and so there is no need
> > to ask for consent again.
> >
> > If the page is not running, or the session id does not match, then no
> > session is established, an so there is no need to ask for consent
> > again.
>
> +1
>
> >> 2) "There's a second screen available that has a pre-existing resumable
> session."
> >>
> >> p.onavailablechange = function(e) {
> >>  if (e.available && e.sessionAvailable) {
> >>    // Pre-existing session found for the same origin, get the user's
> consent:
> >>    session = p.requestSession('http://example.org/', 'foobar', /*
> onlyReconnect */ true);
> >>    // "example.org wants to ..."
> >>  } else {
> >>    console.log('No resumable sessions found, do something else.');
> >>  }
> >> };
> >>
> >> I think 2) allows easier resuming of pre-existing sessions. The names
> of the flags to be bikeshed :-)
> >
> > However I still think like 2) makes for slightly simpler code. So it
> > might still be worth using.
> >
> > But I still think that we should use the semantics described above for
> > onlyReconnect. I.e. when onlyReconnect is set to true the API
> > guarantees that no user consent UI is shown. That is useful to handle
> > the case when for example the session on the TV dies between when the
> > device discover that there's a TV with a session, and the call to
> > requestSession happens.
>
> My personal preference leans toward 2) too.
>
> >> I'm wondering if there are implementability concerns in making the
> PresentationSession available directly on the "presenting" page via the
> "session" property. For example, what would this log on the "presenting"
> page assuming there's a pre-existing session. Also would this call be
> non-blocking?:
> >
> > Before anything at all can be loaded on the presenting device, the
> > controlling device needs to send the URL to the presenting device.
> > Once the controlling device receives the URL, it seems to me that it
> > has enough information that it can create a session object.
>
> Right.
>
> All - it seems it would be fine also from the process perspective to
> continue to update the CG spec and publish an updated version of it. The
> improvements discussed in this thread could be landed into the updated spec.
>
> The CG can then provide the updated spec to the WG as further input. This
> allows us to evolve the spec in the CG in parallel to the WG creation, and
> do the handover when the WG is up and running.
>
> MarkF - feel free to contribute concrete spec updates. I’d guess Dominik
> is happy to help you with the tooling if he gets some PRs in turn :-)
>

Thanks Anssi, catching up to this thread, so please ignore my earlier
question Dominik.    I don't mind authoring PRs with the consensus once
this thread converges.

m.