- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 May 2015 18:22:40 +0000
- To: public-secondscreen@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 examples)? -- GitHub Notif of comment by mfoltzgoogle See https://github.com/w3c/presentation-api/issues/81#issuecomment-101766854
Received on Wednesday, 13 May 2015 18:22:41 UTC