- From: mwatson2 via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Apr 2015 16:58:16 +0000
- To: public-secondscreen@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