Re: Google/Mozilla Presentation API update

On Thu, Aug 14, 2014 at 8: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.
>
> 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.

Won't we have to support the v1 version forever if the API v1 becomes
somewhat popular? It also would be yet another messaging API for the web
developers to handle. I think we'd better reuse an already existing
interface that fits the purpose well with a few fields and methods
undefined or being a noop reserved for the future (e.g. protocol could at
some point actually contain a hint as to what is going on if it turns out
to be helpful for developers). I assume we can state that it's just the
interface that matches the RTCDataChannel while the underlying protocol
doesn't have to be the one defined by the WebRTC spec.

>
> / Jonas