Re: Google/Mozilla Presentation API update

On Fri, Aug 15, 2014 at 2:31 AM, Kostiainen, Anssi
<anssi.kostiainen@intel.com> wrote:
>> In order to make this flow slightly more efficient we could in step 8
>> include in the "onavailablechange" event include a flag indicating
>> that a presentation for the same origin is already running. That way
>> AwesomeGame could avoid doing step 9 in most cases when AwesomeGame
>> wasn't running on the TV.
>
> I think this also partly addresses the concern some participants had with regard the semantics of the "availablechange" (and also "present") event.
>
> By just listening to the events, without asking for user's consent, the initial API tells the "controlling" page the following:
>
> 1) "There's a second screen available."
>
> You'll need to call requestSession() to figure out whether there is a resumable session available. This means there's no programmatic means to check for resumable sessions without user's consent.

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.

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

>>>> As a secondary aspect an API that exposes the PresentationSession as a property of NavigatorPresentation would be easier for Web developers, as they don't have to race against the browser firing the onpresent event too soon, before their event handler is registered.
>>>
>>> Sounds good to me. Would you still prefer to keep the present event, or use Object.observe() to observe the changes? I recall discussing this design with Dominik, so he may have some implementability related comments.
>>
>> Would the property ever change? If the page is started on the TV then
>> the session object would be there when the page first starts and would
>> never go away. If the page is started on a device, the session
>> wouldn't ever be there.
>>
>> requestSession would still return a PresentationSession, so that's how
>> the page on the device gets hold of the session.
>
> Right. To make sure I got this right, this is what is proposed (please fix any bugs):
>
> * drop "onpresent" event handler from the NavigatorPresentation interface
> * add "session" attribute to the NavigatorPresentation interface
> * drop the PresentEvent interface
> * The "session" attribute exists on the "presenting" page only. The "controlling" page can get hold of the session via requestSession()

Correct.

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

> <script>
> window.onload = function () {
>   console.log(navigator.presentation.session.state);
> };
> </script>

So yes, this will be non-blocking.

> I guess we could spec this in such a way that the implementation will wait until the session is established, all the subsystems initialized, before the "controlling" page gets loaded.

That was my assumption that that would effectively be the case anyway.

/ Jonas

Received on Friday, 15 August 2014 22:01:25 UTC