RE: Updated Proposal: Yes/No Availability, UA Screen Selection, Disconnect Notification on Both Sides

Hi Dominik,



Thx for your effort and apologize for late reply. Please find my comments/feedback to some questions from the Wiki:

* [Question copied from the wiki] Do we need to insert into the description an additional permission prompt to grant the page access to the "one ore more screens are available" Information?

** [My comment]: In my point of view the screen availability don't have any security/privacy implications since the web page cannot get additional information about the available screens (number, types, screen resolutions).

* [Question copied from the wiki]  If there are already connected screens when the page subscribes to the onavailablechange event, we can handle this in two ways: We can synthesize one initial event to notify the page about available screens as soon as the first event handler is installed (as described). Or we can add another message like navigator.presentation.getAvailable(function(available) { } ); to notify the page about available screens using this one-time asynchronous getter. Which way should we go?

** [My comment]: I prefer the event-based way in combination with the new state type "resumed" (related to your question "Do we need an additional state like resumed in order to identify resumed session?").  If others prefer the on-demand way using navigator.presentation.getAvailable, I think we need to refine it like navigator.presentation.getAvailable(url, function(session) { } ); where "url" is the URL of the second screen page and "session" the found session or null.
* [Question copied from the wiki]  Do we still need to pass an options parameter to the requestSession() call in order to specify continuous playback or would we leave this an implementation detail to the UA? Given that there is a close() function and disconnect notifications through the state property, this should be sufficient to implement the continuous playback use case.

** [My comment]: I don't think we need the options parameter anymore.



Best regards,

Louay



> -----Original Message-----

> From: Rottsches, Dominik [mailto:dominik.rottsches@intel.com]

> Sent: Mittwoch, 19. Februar 2014 16:22

> To: public-webscreens@w3.org

> Subject: Updated Proposal: Yes/No Availability, UA Screen Selection, Disconnect

> Notification on Both Sides

>

> Dear participants,

>

> thank you again for your helpful feedback on the previous draft.

>

> Based on feedback from Google, Fraunhofer FOKUS and Netflix and our related

> discussion on the mailing list, we now posted an updated proposal on the Wiki

> page:

> https://www.w3.org/community/webscreens/wiki/API_Discussion

>

> - We have changed the availability/discovery from providing a list to simple

> yes/no availability.

>

> - Screen selection is done through a dialog/UI provided by the UA.

>

> - There is no MessagePort object any more. Instead, the characteristic

> MessagePort functions postMessage & onmessage have been exposed on the

> new wrapper object "PresentationSession" directly. This is meant to simplify

> communication. The session object is used on both ends, opener page and

> presentation page, in order to communicate and monitor connection status.

>

> We hope this accurately reflects and builds upon what has been discussed

> before.

>

> Again in this iteration, we list a couple of open questions. Your comments on

> those open questions, as well as any other feedback you may have is of course

> very welcome.

>

> Dominik