Re: [presentation-api] Rethinking availability monitoring

I can see the logic in having an approach that meets the two use cases
 described ("one-shot" and "continuous", for want of better ways of 
describing them) - particularly if it enables the UA reduces power 
consumption.

In this idea mentioned earlier in this thread:

    interface AvailabilityListener : EventTarget {
    Promise<boolean> getAvailability();
        attribute EventHandler onavailablechange;
    }

I'm wondering about the semantics of getAvailability()...

The proposal shows a <boolean> 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?

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.

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

---

I'm also interested by the suggestion that the URL and additional 
params get passed to the availability checking process.

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?

----

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.

Perhaps this would also provide a route to a clean mapping for DIAL 
too?


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

Received on Wednesday, 13 May 2015 14:49:15 UTC