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 
would
trigger display selection and presentation of content. I think this
use-case may be more common than the one in which remote display of 
content
is automatic as soon as an available display appears.

On Mon, Apr 27, 2015 at 8:28 AM, Oleg Beletski 
<notifications@github.com>
wrote:

> Hi All,
>
> First of all, I agree with Anssi, that availability monitoring could
 be
> 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 
out
> whether there are available display(s), and if yes, show content on 
the
> display chosen by the user." I would like to make an addition to 
that
> description - "if external device is not found then stop monitoring 
and
> 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 
the
> display chosen by the user." + keep monitoring for new devices 
because
> there could be better presentation destination appearing in the 
future. We
> should keep discovery process running in that case. Additionally, we
 need
> 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 
methods:
> to acquire position once, to start continuous watching and stopping 
the
> watch. We can follow the same pattern here:
>
> partial interface NavigatorPresentation {
>   Promise checkForAvailability(/*DOMString presentationUrl, 
params*/);
>   Long watchForAvailability(/*DOMString presentationUrl, params*/);
>   clearAvailabilityWatch( long watchId);
> }
>
> Method checkForAvailability runs discovery one time and stops after 
that.
> Last two methods would provide exactly the same functionality that 
is
> available in current design with callback attribute 
onavailablechange and
> corresponding event. New approach makes developers aware that 
browser
> starts doing extra work when monitoring in active. All that clarity 
comes
> 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
> 
<https://github.com/w3c/presentation-api/issues/81#issuecomment-96709089>.
>


-- 
GitHub Notif of comment by mwatson2
See 
https://github.com/w3c/presentation-api/issues/81#issuecomment-96740559
Received on Monday, 27 April 2015 16:58:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 27 April 2015 16:58:18 UTC