Re: Google/Mozilla Presentation API update

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

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

Allowing a site to pass a presentationId + onlyReconnect flag gives it more
control of the tradeoff between convenience and access control.  In the
scenario Jonas describes, the site would use a well-known identifier for
the presentation so it can easily reconnect, at the expense of allowing
connections from any other site that knows the user's email address.

To give further access control, we might also explore a CORS-like access
control mechanism so that the presentation can whitelist certain pages for
reconnection.


>
> 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 the requestSession check should be able to be computed quickly
(either the browser is aware of the presentation or not) so perhaps this
isn't necessary.

m.


> >> 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 the messaging API should expose capabilities and not be tied to a
particular implementation.  In particular I want to make sure that the API
is restricted to network serializable data types, and this happens to
coincide with the capabilities of the RTCDataChannel and WebSocket APIs.

Ideally there would be an interface declared for this that would be
mixed-in to all APIs that are (or could be) implemented by network
serialization.


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

That sounds fine, postMessage(DOMString) is a subset of the API we are
discussing here from a capabilities point of view.  Although I think we
would rename it to send(...) to remain parallel with RTCDataChannel and
WebSocket.

m.


> / Jonas
>