Re: Google/Mozilla Presentation API update

Hi Jonas, Dominik,

On 14 Aug 2014, at 22:46, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 14, 2014 at 2:04 AM, Kostiainen, Anssi
> <anssi.kostiainen@intel.com> wrote:

[...]

> If the presentationId was handed back to the game when requestSession
> was called in step 4, that means that the game would have to sync this
> presentationId to all devices for step 9 and 10 to work. Being able to
> specify the presentationId makes this a lot easier for the application
> to implement the resume logic.

That’s a realistic and good use case IMO.

I think the “presentationId" should be developer configurable as Jonas proposes, instead of a unique identifier generated by the implementation.

This would be similar to how Shared Workers’ name is developer configurable. Unless we have evidence that shows Shared Workers design (that has shipped) is insecure, I think we should make the attribute configurable.

> Even in the scenario when the user uses the same device to resume the
> session this model is easier. If the presentationId is handed back,
> then AwesomeGame would have to store that presentationId in IndexedDB
> or similar and manage the logic of when to remove it.

Right.

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

var p = navigator.presentation, session;

p.onavailablechange = function(e) {
  if (e.available) {
    // requestSession() shows the screen picker UI to get user’s consent.
    // The user would be shown only resumable sessions if the requestSession()
    // call has its onlyReconnect flag set. If the user dismisses the UI, then
    // no statechange is fired. 
    session = p.requestSession('http://example.org/', ‘foobar', /* onlyReconnect */ true);

    // statechange fired when the user selects the screen from the picker.
    session.onstatechange = function() {
      if (session.state === 'connected') {
	// Got a resumable session
      }
    };
  }
};

Jonas’ proposal 2) would give the web developer more information and control over sessions before the picker UI is shown to the user:

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

Assuming there’s no concerns in giving information on the availability of the resumable sessions without user’s consent, I think 2) does address the use case better. Given we’ll operate within the same origin, I guess that’s not a concern. Of course, implementation could ask for user’s consent upon availablechange listener registration, but I think event registration should not have such side-effects.

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

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

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

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.

[We had a similar discussion in the context of the Battery Status API recently in the Device APIs WG, and opted-in to an async means to get the data to get it off the critical path, instead of providing the data via a sync accessor.]

>>> 3. Message passing API.
>>> 
>>> The current spec only allows DOMString to be passed via the messaging API.  We would like to allow efficient transfer of binary payloads via this API; this would allow the presenting page to e.g. stream a bundle of resources needed for the presentation to the presenting page, or to share a locally created binary data stream with the presenting page (e..g, from MSE [4]).
>>> 
>>> To this end, aligning the messaging API with the one exposed by RTCDataChannel makes sense [3], specifically the send(), close(), and onmessage parts of the API.
>>> 
>>> [3] http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel
>>> [4] http://www.w3.org/TR/media-source/
>>> 
>>> We don't want to tie the Presentation API spec to the RTCDataChannel implementation, but would like there to be interface compatibility, as WebRTC would be a likely mechanism for implementing peer-to-peer communication between user agents.
>> 
>> Do you suggest PresentationSession implements RTCDataChannel in addition to its current messaging API, or instead of it?
> 
> The goal would be to *not* expose a RTCDataChannel interface right now
> since we don't want to force implementations to use any particular
> network protocol (at least that's my understanding of the group's
> current goals). The idea would be that possibly in the future we can
> expand the messaging API to maybe use a fullblown RTCDataChannel. But
> for now the goal is just that such possible future a change would be
> backwards compatible.

+1

>> I think we'd like to make sure the simple use cases that require only DOMStrings are easy to implement, so we'd like to keep the messaging API around for simplicity.
>> 
>> Perhaps phasing could be used here as well: in v1 spec the messaging API, make the RTCDataChannel a v2 feature.
> 
> Agreed. The goal is to make sure that v2 is backwards compatible with v1.


Dominik - do you think you could open GH issues for these improvements so we could keep track of the updates?

Thanks,

-Anssi

Received on Friday, 15 August 2014 09:32:26 UTC