Re: [presentation-api] Rethinking availability monitoring

Hello all,

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?



regards


Matt

--
| Matt Hammond
| Senior Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/


> On 11 May 2015, at 23:20, Anton Vayvod via GitHub <sysbot+gh@w3.org> wrote:
>
> We could just monitor availability as long as the received
> AvailabilityListener instance is alive. The downside is that if the
> page
> discards the instance but attached a listener to it beforehand, the
> instance will live as long as the page. I'm not sure about the use
> case
> though when a presentation capable page would want to stop discovery
> unless
> it was navigated from. Are there any existing examples why this is
> needed
> on a more granular level than "page is closed/navigated"?
>
> The URL and optional parameters could be used for device filtering in
> the
> future.
>
> Rather than add a cancel method we could write the
> AvailabilityListener API
> as follows:
>
> partial interface NavigatorPresentation {
>  AvailabilityListener listenForAvailability(/*DOMString
> presentationUrl,
>      params*/);
> }
>
> interface AvailabilityListener : EventTarget {
>  Promise<boolean> getAvailability();
>  attribute EventHandler onavailablechange;
> }
>
> The UA would not run discovery if:
>
>   - there were no handlers on onavailablechange
>   - there was no unresolved Promise from getAvailability
>
> Even if there were listeners, the UA could also suspend discovery if
> there
> was no opportunity to start presentation (i.e., screen was off, tab
> was in
> the background, etc.) as a power optimization.
>
> I would like to understand the role of the presentationUrl and params
> in
> the API; @avayvod <https://github.com/avayvod>, they were part of your
> original proposal.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/presentation-api/issues/81#issuecomment-101039366>.
>
>
> --
> GitHub Notif of comment by avayvod
> See
> https://github.com/w3c/presentation-api/issues/81#issuecomment-101065154

>



-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Tuesday, 12 May 2015 16:23:39 UTC