Re: Rethinking availability monitoring

Hi,

> On 25 Apr 2015, at 01:21, 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.

Thanks for the feedback! The promise-returning attribute is fairly bleeding edge thing, not in use widely, so I wasn't sure whether it would work here.

I opened an issue for this:

  https://github.com/w3c/presentation-api/issues/81

Also added this to the F2F agenda.

> (1) There can be multiple availability transitions, and the Promises guide encourages use of Promises for one time events, but not recurring events [1].

When crafting the proposal, I was looking at:

[[

In certain cases, promises can be useful as a general mechanism for signaling state transitions. This usage is subtle, but can provide a very nice API for consumers when done correctly.

http://www.w3.org/2001/tag/doc/promises-guide#state-transitions

]]

... which seemed to suggest this *might* work.

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

Since .ready signals display availability the author should not care at this point given she has a session object already (that has .state to monitor PresentationSessionState).

.ready would resolve here as long as displays N>1.

> }
> 
> function endSession() {
>   // Clean up previous session
>   // We might end up missing the next unavailable -> available transition here?

Good catch. That transition we could not catch with a single .ready, so calling .ready here would resolve even if the state had transitioned to unavailable and back to available in between.

Analogous to roaming from a room to another, while connecting the device with HDMI, yielding a state transition:

connected -(1)-> disconnected -(2)-> connected

The (1) transition would be singled via PresentationSession.state === "disconnected".

The (2) transition would be undetected.

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

All - if you feel like experimenting further with the examples please feel free to do so, and post your results at:

  https://github.com/w3c/presentation-api/issues/81

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

My understanding was that .ready would resolve when the number of available displays goes from zero to N, where N>1. That in itself would not trigger a presentation request, just inform the web author that there are displays available. The browser chrome might lit some indicator a la web audio in use at this point too, but that's an implementation detail.

Only when startSession() or joinSession() would be called, there would be a presentation request to ask for user permission.

Thanks,

-Anssi (WG chair)

> [1] http://www.w3.org/2001/tag/doc/promises-guide#recurring-events

Received on Monday, 27 April 2015 15:29:28 UTC