Re: Google/Mozilla Presentation API update

On Thu, Aug 14, 2014 at 2:04 AM, Kostiainen, Anssi
<anssi.kostiainen@intel.com> wrote:
> On 14 Aug 2014, at 03:05, mark a. foltz <mfoltz@google.com> wrote:
>> An alternative proposal allows the application to pass in its own presentation identifier and determine whether the presentation request should only reconnect, or potentially create a new presentation:
>>
>> partial interface NavigatorPresentation : EventTarget {
>>
>>
>>
>>   PresentationSession requestSession(DOMString url,
>>                                      optional DOMString presentationId,
>>                                      optional boolean onlyReconnect);
>> }
>>
>> [1] http://www.w3.org/TR/workers/#shared-workers-and-the-sharedworker-interface
>
> Either one of the alternatives seem to address the use case. Which of the options you think makes the common use case the simplest?

The advantage of the 'onlyReconnect' approach is that it simplifies
the model for application developers. Consider for example if
AwesomeGame enabled playing the game on your TV. With the
'onlyReconnect' solution it could do the following

1. User installs AwesomeGame on two devices.
2. User "logs in" to the game on both devices. For example using
facebook connect or Google accounts. This could bring other benefits
such as syncing game progress between devices, or sharing highscores
with friends.
3. User starts playing AwesomeGame on one of her devices.
4. AwesomeGame uses the presentation API to use the TV as display.
5. AwesomeGame uses the user's email address as "presentationId".
6. The device runs out of battery.
7. The user picks up second device and launches AwesomeGame.
8. AwesomeGame on the second device receives event indicating that a
remote TV is available.
9. AwesomeGame optimistically calls requestSession with the user's
email address as presentationId and onlyReconnect set to true.
10. User can seamlessly resume her game.

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.

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.

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.

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

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

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

/ Jonas

Received on Thursday, 14 August 2014 19:47:19 UTC