Re: Rethinking availability monitoring

I think that Anton's proposal would be a great benefit over the current
model.

I am tempted to do some bikeshedding too but I will leave that to editors
and implementors ;). Though, I think that at least listenForAvailability()
should be renamed to to getAvailability() or availability().

-- Mounir

On Mon, 27 Apr 2015 at 16:31 Kostiainen, Anssi <anssi.kostiainen@intel.com>
wrote:

> Hi Anton,
>
> > On 25 Apr 2015, at 22:03, Anton Vayvod <avayvod@google.com> wrote:
> >
> > Having discussed this with Mounir recently, the right approach would be
> to return an object via Promise that has a bool and an event handler. This
> way the UA doesn't have to do weird tricks like detect if anything is
> subscribed to the event to start/stop discovery, there's no compromise
> between the attribute being initialized or firing the event immediately
> after a listener is attached and even gives more flexibility if the page
> wants to filter the events - pass the parameters to the Promise returning
> method.
> >
> > partial interface NavigatorPresentation {
> >   Promise<AvailabilityListener> listenForAvailability(/*DOMString
> presentationUrl, params*/);
> > }
> >
> > interface AvailabilityListener : EventTarget {
> >   readonly attribute boolean available;
> >   attribute EventHandler onavailablechange;
> > }
> >
> > One may need some way to discard the listener to signal the UA that the
> page is not interested in the screens anymore.
> >
> > WDYT?
>
> Thanks, this looks good to me, perhaps with some bikeshedding about naming
> :-)
>
> We've used a similar design in other specs, for example:
>
> * Battery Status API (http://www.w3.org/TR/battery-status/)
> * Permissions API (https://w3c.github.io/permissions/)
>
> ... so this has proven to work and is implementable.
>
> Thanks,
>
> -Anssi (WG chair)