W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2015

Re: [presentation-api] Rethinking availability monitoring

From: mwatson2 via GitHub <sysbot+gh@w3.org>
Date: Mon, 27 Apr 2015 16:58:16 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-96740559-1430153896-sysbot+gh@w3.org>
Another common use-case is "Find out whether there are available
displays(), and if yes, show an icon to the user. When there are no
available displays, remove / dim the icon". Clicking the icon is what 
trigger display selection and presentation of content. I think this
use-case may be more common than the one in which remote display of 
is automatic as soon as an available display appears.

On Mon, Apr 27, 2015 at 8:28 AM, Oleg Beletski 

> Hi All,
> First of all, I agree with Anssi, that availability monitoring could
> improved and because of multiple reasons. One of the reasons is that
> current API design makes it very simple for web developers to start
> continuous monitoring and then to forget stopping it. Discovery is
> expensive process that could prevent device from entering power
> saving/efficient mode.
> I also agree that it is good to optimize the most common one "Find 
> whether there are available display(s), and if yes, show content on 
> display chosen by the user." I would like to make an addition to 
> description - "if external device is not found then stop monitoring 
> forget that we ever wanted to use the second screen".
> Then there is a less common case that we still need to support - 
"Find out
> whether there are available display(s), and if yes, show content on 
> display chosen by the user." + keep monitoring for new devices 
> there could be better presentation destination appearing in the 
future. We
> should keep discovery process running in that case. Additionally, we
> to provide for developers an explicit mechanism for stopping 
discovery then.
> After listing those cases side by side I realized that I have 
already seen
> that approach implemented in Geolocation API [1]. There are three 
> to acquire position once, to start continuous watching and stopping 
> watch. We can follow the same pattern here:
> partial interface NavigatorPresentation {
>   Promise checkForAvailability(/*DOMString presentationUrl, 
>   Long watchForAvailability(/*DOMString presentationUrl, params*/);
>   clearAvailabilityWatch( long watchId);
> }
> Method checkForAvailability runs discovery one time and stops after 
> Last two methods would provide exactly the same functionality that 
> available in current design with callback attribute 
onavailablechange and
> corresponding event. New approach makes developers aware that 
> starts doing extra work when monitoring in active. All that clarity 
> with the price of adding new methods to proposed API. The other 
thing is
> that proposal mixes promises and callbacks together. I am sure, 
there might
> be a better way to design it.
> [1] http://dev.w3.org/geo/api/spec-source.html#geolocation_interface
> —
> Reply to this email directly or view it on GitHub

GitHub Notif of comment by mwatson2
Received on Monday, 27 April 2015 16:58:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:52 UTC