Re: Rethinking availability monitoring

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?

On Sat, Apr 25, 2015 at 12:21 AM, mark a. foltz <mfoltz@google.com> wrote:

> Anssi,
>
> I think your proposal helps the common use case, but has some pitfalls.
> I'll provide some feedback here but feel free to open a GH issue for
> further discussion.
>
> (1) There can be multiple availability transitions, and the Promises guide
> encourages use of Promises for one time events, but not recurring events
> [1].    Promises can only be resolved once, so the ready attribute would
> have to be refreshed with a new Promise after each transition.  But the
> author doesn't know when that new Promise might be available.   What would
> the code look like - maybe:
>
> navigator.presentation.ready.then(function(p) {
>   p.startSession('http://example.org')
>    .then(setSession)
>    .catch(endSession);
> });
>
> function setSession() {
>   // Do we need to await navigator.presentation.ready while a session is
> in progress?
> }
>
> function endSession() {
>   // Clean up previous session
>   // We might end up missing the next unavailable -> available transition
> here?
>   navigator.presentation.ready.then(function(p) {
>     p.startSession('http://example.org')
>      .then(setSession)
>      .catch(endSession);
> });
>
> Perhaps developing a longer code sample in the GH issue showing handling
> of both available -> unavailable and unavailable -> available transitions
> would let us get a clearer picture.
>
> (2) If the UA were to (for example) roam onto a wireless network with a
> presentation screen, the user would suddenly see a presentation request,
> which seems a little odd.
>
> [1] http://www.w3.org/2001/tag/doc/promises-guide#recurring-events
>
> m.
>
> On Tue, Apr 21, 2015 at 6:53 AM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
>
>> Hi All,
>>
>> I was thinking whether we could optimize the display availability
>> monitoring API for the following common use case:
>>
>> "Find out whether there are available display(s), and if yes, show
>> content on the display chosen by the user."
>>
>> What follows is a proposal to add a promise-returning "ready" attribute
>> to the NavigatorPresentation interface. The proposal is inspired by the
>> similarly named attribute in Service Workers [1]. Also noted in [2].
>>
>> Here's the proposed IDL addition:
>>
>> interface NavigatorPresentation : EventTarget {
>>   // ...
>>   readonly attribute Promise<NavigatorPresentation> ready;
>> };
>>
>> The promise-returning "ready" attribute never rejects, resolves with the
>> NavigatorPresentation object itself when one or more displays become
>> available. Also works if the availability state is changed before the
>> "ready" property is accessed thanks to the built-in microtask. In such a
>> case, the promise returned will immediately resolve after the attribute is
>> accessed.
>>
>> I think this makes the common use case easier to implement for web
>> authors than the events-based model, and addresses the following issue
>> related to the use of events: one must be subscribed to the
>> "availablechange" event when it is fired, otherwise the availability
>> information is lost.
>>
>
> The algorithm for adding an event handler to onavailablechange [2] was
> intended to require that the UA fire an event with the current availability
> status, so it's not dependent on timing.  It looks like the spec is not as
> explicit as it should be on that point however.  I can address that with a
> PR.
>
> [2]
> http://w3c.github.io/presentation-api/#adding-an-eventhandler-to-onavailablechange
>
>
>> Here's an example using the proposed promise-returning "ready" attribute:
>>
>> navigator.presentation.ready.then(function(p) {
>>   p.startSession('http://example.org')
>>   .then(setSession)
>>   .catch(endSession);
>> });
>>
>> This is basically the same as examples [3] and [4] combined.
>>
>> The events-based API is still required for use cases in which the state
>> transition from "displays available" to "displays unavailable" is relevant.
>> We could mint another promise returning attribute for that state transition
>> too, and be able to drop the "availablechange" event and the
>> AvailableChangeEvent interface.
>>
>> WDYT? Any bugs/issues? I'll create an issue for this if no one shouts, so
>> we can investigate further whether this is a good idea.
>>
>> Thanks,
>>
>> -Anssi (WG chair)
>>
>> [1]
>> http://www.w3.org/TR/service-workers/#service-worker-container-ready-attribute
>> [2] http://www.w3.org/2001/tag/doc/promises-guide#example-9319da00
>> [3]
>> http://w3c.github.io/presentation-api/#monitor-availability-of-presentation-displays-example
>> [4]
>> http://w3c.github.io/presentation-api/#starting-a-new-presentation-session-example
>>
>>
>>
>>
>>
>