Re: [presentation-api] Rethinking availability monitoring

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

Thanks for the explanation. I understand the intended behaviour now.

I would suggest that the method returning the promise be named 
something such as `checkAvailability` or `determineAvailability`. For 
me, `getAvailability` implies a passive retrieval of some kind of 
state information and led me to my previous conclusions.

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

Yes, this is what I had in mind. Parameters needed in the process of 
establishing availability and/or starting/joining the session.

> Perhaps @avayvod can clarify the use of parameters (and show some 
examples)?

I can offer some strawman examples for that would be useful for an 
implementation that can launch applications on an HbbTV 2.0 
television/set-top-box:

* `hbbtv.appId` (integer) and `hbbtv.orgId` (integer) ... necessary to
 allow the presentation to combine itself with broadcast content
* `hbbtv.appEndpoint` (string) ... needed to establish the 
communication channel.



-- 
GitHub Notif of comment by matt-hammond-bbc
See 
https://github.com/w3c/presentation-api/issues/81#issuecomment-101772960

Received on Wednesday, 13 May 2015 18:44:43 UTC