Re: Google/Mozilla Presentation API update

On Fri, Aug 15, 2014 at 10:31 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:
>
> 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 :-)

Each time I see a boolean flag in the parameters list I feel like having
two functions instead with distinctive clear names instead. Maybe have two
functions like this:

partial interface NavigatorPresentation {
  PresentationSession startSession(DOMString url, DOMString sessionId);
  PresentationSession joinSession(DOMString url, DOMString sessionId);
}

Also, what do the function(s) return if the session is not established
(e.g. user exits the selection UI by dismissing the popup menu or there's
no existing session to join) ? An uninitialized useless session object? Or
should we change the return type to a Promise that passes a session to the
caller if it succeeds?

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