Re: [presentation-api] Rethinking availability monitoring

> On 13 May 2015, at 14:28, Oleg Beletski <o.beletski@samsung.com> wrote:
> 
> Hi All, 
> 
> That discussion started originally in https://github.com/w3c/presentation-api/issues/81. Should we try to move it back there? 

Apologies ... will replicate my comments there.

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


> On 13 May 2015, at 14:28, Oleg Beletski <o.beletski@samsung.com> wrote:
> 
> Hi All, 
> 
> That discussion started originally in https://github.com/w3c/presentation-api/issues/81. Should we try to move it back there? 
> 
> Otherwise, CIL
> 
> 
>> -----Original Message-----
>> From: Matt Hammond [mailto:Matt.Hammond@bbc.co.uk]
>> Sent: 12 May 2015 19:23
>> To: public-secondscreen@w3.org
>> Subject: 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).
>> 
> 
> [Oleg] I would expect that each time getAvailability is called for pure one-shot case new discovery process is started and new promise returned. That means that promise will never resolve immediately. Then it is less obvious what is going to happen if we have callbacks attached and getAvailability is called after that. In that continuous discovery mode UA should be aware about all screens discovered and returned promise will resolve immediately.
> 
>> 
>> 
>> 
>> 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?
> 
> [Oleg] Completely agree that we need to pass additional parameters when discovery/availability started, e.g. discovery timeout value.
> 
>> 
>> 
>> 
>> 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-

>> 1010651
>>> 54
>>> 
>> 
>> 
>> 
>> -----------------------------
>> 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 Wednesday, 13 May 2015 13:35:33 UTC