RE: Presentation API changes proposal

Dear Anton, Kostiainen,



I also like the proposal of Anton.   We have also a proposal I merged it in the spec propose by Anton:



Promise requestShow(optional DOMString url = "about:blank" | DOMElement elem, optional boolean infinitePlay = false);



In case the first parameter is a DOM Element, The DOM Subtree starting by this element will be displayed on the second screen. Any manipulation  in the DOM subtree on the original document (first screen device) results in updating the copy on the second screen (MutationObservers[1] is one possible way to observe changes). Updates can be sent for example over a RPCDataChannel.





[1] http://www.w3.org/TR/dom/#mutation-observers



Best regards,
| Dipl.-Ing. Louay Bassbouss
| Project Manager
| Future Applications and Media
|
| Fraunhofer Institute for Open Communication Systems
| Kaiserin-Augusta-Allee 31 | 10589 Berlin | Germany
| Phone 49 30 - 3463 - 7275
| louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.fraunhofer.de>
| www.fokus.fraunhofer.de<http://www.fokus.fraunhofer.de/>






-----Original Message-----
From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
Sent: Mittwoch, 8. Januar 2014 11:46
To: Anton Vayvod
Cc: public-webscreens@w3c.org; Miguel Garcia; Peter Beverloo
Subject: Re: Presentation API changes proposal



Hi Anton,



On 07 Jan 2014, at 18:10, Anton Vayvod <avayvod@google.com<mailto:avayvod@google.com>> wrote:



> Dear all,

>

> Even before Google joined the Second Screen Presentation Community Group, we had been closely following the development of the Presentation API[1].



I'm happy to see you and other Googlers join the group. Welcome!



> We would like to propose some changes to the specification in order to allow not just mirroring technologies to be built on top of it, but also allow media flinging technologies (like Chromecast, [2]). In that case, one user agent triggers and controls the content on the second screen, while a second user agent displays the content and responds to the commands it receives.

>

> This would have some implications on the API itself: it would become possible for media to continue playing, even when the user agent that triggered it is killed, for example because the associated tab has been closed. Because of that, we would also need to be able to connect to already in-progress sessions.



Thanks for your detailed feedback. Generally, your proposal looks good to me considering the use case. Some comments below.



> With that in mind, the first change we would like to propose to the API is as follows:

>

> Promise requestShow(optional DOMString url = "about:blank", optional boolean infinitePlay = false); [3]

>

> Calling requestShow with a url of a session in progress would return the WindowProxy (or MessagePort) of the session in progress instead of prompting the user.



I guess there would be no prompt only if there already exists a session identified by an url and infinitePlay is set to true? Am I right that the infinitePlay flag controls whether the media will continue to play even if the browsing context from which the requestShow() was called is destroyed?



The step 4 of the /algorithm to request access to the presentation display/ currently says:



[[



* Prompt the user's permission or check that the setting for allowing access to a presentation display enabled. If no permission is given, jump to the step labeled failure below. If the user never responds, this algorithm will never progress beyond this step.



]]



We may need define a "check that the setting for allowing access to a presentation display" process (should make the name more concise), and clarify this detail in it. Also some other steps may need to be adjusted a bit. Do you already have a concrete proposal in mind how you'd like to change the algorithm?



Btw. How in the flinging use case you'd identify a session? Is the url enough (e.g. use a query string and/or fragment identifier to conveying the session information), or is something else required? For example, how about a use case where a video from the same url is being played on two separate secondary displays?



> On top of this change, we'd also like to explore two other things that would make the API easier to implement and use.

>

> Promise searchSecondScreens(optional DOMString url);

>

> This would replace displayAvailable and onDisplayAvailableChange. The promise would return true if there is at least one display available for this url. The implementation of the method can certainly cache devices and keep a similar displayAvailable + event handler mechanism internally.



In addition to making the API more future-proof, this would actually be a requirement for the flinging use case to work if I'm not mistaken? There must be a means to filter the search with an url that identifies a session (if enough to identify a session, that is). Other than that, this seems to be functionally-equivalent with the current design.



> Finally we'd like to change the spec so that the Promise object can return a small wrapper over MessagePort instead of a WindowsProxy. Implementing a full WindowsProxy will add additional and unnecessary complexity, making browser implementations harder without a need.



Do you have more details to share on how you'd propose the MessagePort to be extended?



> Please do let us know if these changes sound too dramatic or unfeasible. We are completely open to ideas and would be happy to be involved in further discussions!



Thanks for the great feedback! I'm sure Dominik will chime in with his editor hat on soonish.



Thanks,



-Anssi



> [1] http://webscreens.github.io/presentation-api/

> [2] http://www..google.com/intl/en-GB/chrome/devices/chromecast/

> [3] http://dom.spec.whatwg.org/#promises