Re: Rethinking availability monitoring

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
>
>
>
>
>