W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Rethinking availability monitoring

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 May 2015 18:22:40 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-101766854-1431541358-sysbot+gh@w3.org>
> The proposal shows a to be passed by the Promise during resolution. 
Presumably this is intended as a flag that is true for availability 
and false for unavailability? Is this what is intended?

Yes, that's what's intended.

> My understanding is that a Promise "resolves" if the system 
transitions to the desired/new state after the promise is made; but 
also resolves immediately if it is already in that state. Therefore if
 this is the intended behaviour then I don't see how it works.

The Promise resolves when the browser has an answer to the query (not 
necessarily when the underlying system changes state).  Since 
answering the question of "are screens available" likely involves 
cross-process or cross-device communication, using a Promise frees up 
Javascript execution while the browser figures that out.

 > I think the only sensible behaviour is for the promise to resolve 
only if there is availability (not unavailability).

Suppose there are no screens available; this means that the browser 
would have to monitor continuously while that Promise is pending.   
This ends up being the same as adding an event handler to 
`onavailablechange` to monitor all availability changes.

> If we go down this route, it then feels redundant to be 
re-specifying the URL (and params?) when subsequently calling 
startSession(). What if a resolved promise notifying of availability 
returned an object that provided the startSession() and/or 
joinSession() methods and carried that state (the URL and any params) 
with it?

If we go with this approach I could see moving `startSession()` to the
 `AvailabilityListener` interface so the URL gets specified once for 
screen availability and presentation request.   `joinSession()` does 
not have a prerequisite of waiting for screen availability so the need
 is less clear.

> Finally, I can see uses for the "params" if provided to the process 
of starting a session. I've been thinking about the relationship 
between HbbTV and this API. It would be useful if the URL can be 
supplemented with additional data that will be used if the URL is 
being launched on an HbbTV device, or ignored if it is not.

I think the params are intended to communicate to the user agent 
additional requirements for the remote screen (yet to be determined).
   For passing information to the remote presentation there are plenty
 of ways  to use URLs: query parameters, URL fragments, or messaging 
after the presentation is connected.

Perhaps @avayvod can clarify the use of parameters (and show some 


GitHub Notif of comment by mfoltzgoogle
Received on Wednesday, 13 May 2015 18:22:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 May 2015 18:22:41 UTC