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

Hi All, Louay,

On 24 Feb 2014, at 14:35, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote:

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

Louay - thanks for the feedback.

> * [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).

Ok, I’m hearing providing the availability information (as a high-level hint as currently discussed) to the web content is not a concern.

This suggest we should not require (as in MUST) this to be gated behind a permission prompt. That said, I think there is nothing that prevents an implementation from doing so if so preferred. We can spec this is such a manner that it is possible, but not required.

> * [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.

The only potential concern with the event-based model I can think of is the following: the event registration can have a side-effect. IOW, adding an event listener may cause an event to be synthesized and dispatched. Some APIs on the platform already behave similarly, but most do not. That said, if this becomes an issue, we can address this by adding a method (e.g. a la MessagePort’s start()) to explicitly start the event dispatch.

> * [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.

Ok. I suggest we leave it out for now. We can add things later if new use cases emerge.

Given no further concerns at this time, we'll draft the revised WebIDL for the proposed API, and send it out for review to this group.

Thanks,

-Anssi

Received on Monday, 3 March 2014 14:59:44 UTC