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