Re: Google/Mozilla Presentation API update

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,

-Anssi

Received on Thursday, 14 August 2014 09:04:58 UTC