Re: Google/Mozilla Presentation API update

On Thu, Aug 14, 2014 at 2:04 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi Mark, Jonas, Anton, et al.,
>
> On 14 Aug 2014, at 03:05, mark a. foltz <mfoltz@google.com> wrote:
>
> > Recently we (Mark and Anton) had a chance to meet with representatives
> from Mozilla (Jonas, Marco, and Wesley) about the current state of the
> Presentation API.  We discussed the following ideas, which we believe will
> help improve the specification that came out of the Community Group and
> make it suitable for the use cases we have in mind.
>
> Thanks for the well-thought-out feedback! In addition to Google’s, I’m
> happy to also see Mozilla’s feedback, and look forward to continued
> participation of all of you once we transition this work into a Working
> Group.
>
> Below are my comments on the proposals, which generally look great to me.
> That said, I’ll let also Dominik review the proposals with his Chromium hat
> on :-)
>
> > Below we refer to the “controlling” page as the one that calls
> requestSession and the “presenting” page as the one that is rendering the
> presented URL.
> >
> > 1.  Reconnection to existing presentations on the controlling user agent.
> >
> > After considering the options, a method to reconnect using a mechanism
> similar to shared workers [1] whereby presenting to a URL already being
> presented would reconnect to that presentation.
>
> I’d +1 the reuse of this mechanism given it has been proven to work with
> Shared Workers.
>
> > It would improve security and ease of use of the API for requestSession
> to take a secure (hard to guess) identifier in conjunction with the URL
> that would be generated by the browser and returned with a new
> PresentationSession.  This way, the initiating page can (1) control who can
> reconnect by sharing that identifier and (2) allow the same URL to
> effectively start a new presentation by requesting it without the
> identifier.  E.g., the API would look like:
> >
> > partial interface NavigatorPresentation : EventTarget {
> >
> >
> >
> >   PresentationSession requestSession(DOMString url,
> >                                      optional DOMString presentationId);
> > }
> >
> > partial interface PresentationSession : EventTarget {
> >
> >
> >
> >   readonly DOMString presentationId;
> >
> >
> >
> > };
> >
> > In some circumstances the page may wish to only reconnect to an existing
> presentation and not start a new one when the page is loaded.  For example,
> if their browser crashes or a tab is accidentally closed, it will want to
> see if the user was presenting before that happened.  In this case the
> initiating page would call requestSession with a previously stored
> identifier, and if the presentation is no longer active, it would
> immediately get a disconnected session.  It can then choose to initiate a
> new session by requesting again without the identifier.
> >
> > It also solves the problem of disconnection, i.e. the site can erase the
> presentation id from its cookies or local storage with the identifier when
> the user logs out, and other pages with access to the same storage would no
> longer be able to access the presentation.
> >
> > 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?
>
> > 2. Cross page navigation on the presenting user agent.
> >
> > If the page hosting the presentation navigates what happens to the
> presentation session? Does the navigated-to-page automatically get a
> PresentEvent or is some access control mechanism necessary?  One option is
> to have the PresentationSession implement Transferable [2] so it can be
> transferred to a Shared Worker on the presentation side, similar to how a
> MessagePort can be transferred between pages and workers.
> >
> > [2]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#transferable-objects
>
> The ability to transfer the PresentationSession objects would indeed
> address this use case by reusing the existing building blocks of the web
> platform (good).
>
> MarkF et al. - what is your experience with Chromecast on this -- I guess
> this is a pretty common use case? Any findings from your implementation
> related to this you’d like to share with the group?
>
> My personal take is there seems to be valid use cases for this, and we
> should not limit this API to single-page web apps only. The most common use
> case I can think of is probably a video site such as YouTube that allows
> the user to navigate around the site while the video is playing on a second
> screen and the user is able to control the playback from any of the pages
> that have access to the Shared Worker, that in turn, has access to the
> PresentationSession.
>
> This will of course add some implementation complexity, so the feature
> could be spec’d and prototyped once we have the basics done first.
>
> > 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.
>
> > 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?
>
> 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.
>
> > 4. User agent context for rendering the presentation.
> >
> > If we intend the same presentation content to be rendered either in the
> same user agent or a remote user agent, we need to carefully define the
> rendering context so that the application doesn’t get different behavior
> according to whether it is rendered remotely or locally.  In particular the
> presentation rendering context must have:
> >
> > - No access to cookies, local storage or IndexedDB instances
> > - No access to HTTP cache
> > - No access to pre-existing SharedWorkers
> > - Extensions are debatable - some may be required for e.g. VPN or
> firewalls to work correctly
> >
> > For performance we would still like to be able to pre-load resources
> needed by the presenting page and to share them with (or stream them to)
> it.  Thus a need for transferring binary blobs efficiently between the two
> sides.
>
> Agreed. These will need to be defined in the evolved specification.
>
> > 5. Remoting <video> presentation remains an important use case for both
> mobile and desktop.  We would like the behavior of the <video> tag to be
> defined in the remote presentation scenario, and offer hooks for web
> developers to customize the behavior of the tag when it is being remoted.
> This might be done as an addendum to the main specification.
>
> Agreed. While prototyping this feature I figured out enabling this
> important use case will make it very easy to turn existing <video> content
> on the Web into second screen capable.
>
> This spec would be in scope for the upcoming Working Group. We can do this
> in its own specification as you say. If the feature would be
> self-contained, as it seems, that would make a lot of sense.
>
> > 6. Some standard for establishing communication between two UAs would be
> very helpful for interoperability for the 2-UA case.  At a minimum, a
> standard serialization and framing of messages that are sent between the
> two sides.  This may not be a specification that is pursued directly within
> the group but may happen alongside.
>
> I think this would be a good exploratory work item for the Community Group
> (once the WG kicks off, this CG should re-evaluate its objectives and this
> would be a good candidate).
>
> "Establishment of a messaging channel between the two parties” is out of
> scope for the proposed Working Group as per the WG Charter.
>
> > 7. A standard way to use the API to take advantage of the millions of
> existing devices that can render a subset of Web content via DIAL or other
> mechanisms.  Again, this is not something that may happen in the CG/WG but
> may be done separately, for example as part of the DIAL specification. [5]
> >
> > [5] http://www.dial-multiscreen.org/
>
> This would be out of scope for the CG and WG. This work could, however,
> happen in other forums.
>
> > We hope to contribute concrete specification updates to address 1-4 as
> well as example code to better illustrate these use cases, depending on
> developer time :)
> >
> > Thanks all, and we welcome feedback.
>
> Mark, Jonas, Anton, et al. - thanks for the very helpful feedback! I’m
> looking forward to us kicking off the Working Group soon so that we can
> continue to evolve the specification on the standards track based on your
> feedback. Meanwhile, let's continue to use this mailing list for any
> related discussions.
>
> Thanks,
>


Thanks Anssi.  Please provide any updates you have on the progress of the
WG :)

m.