Re: [presentation-api] Rethinking availability monitoring

During F2F meeting we agreed to have an `AvailabilityListener` for 
explicit monitoring of screen availability. We also agreed that cancel
 method is not required and UA start/stop discovery when needed. 
Actually there were two proposals and we did not look in the details 
at second modification of the original interface. Let’s take a second 
look and compare both. The main difference is that in the first 
proposal access to the `AvailabilityListener` is behind the promise 
and in the second proposal access to one method of the interface 
returns the promise for the user - `getAvailability()`. In both cases 
there is only one promise that user code has to wait to resolve.

**First proposal:**
```
partial interface NavigatorPresentation {
  Promise<AvailabilityListener> listenForAvailability(…);
}

interface AvailabilityListener : EventTarget {
  readonly attribute boolean available;
  attribute EventHandler onavailablechange;
}
```
Access to the interface is behind the promise. Discovery starts when 
interface is instantiated even if there is no event listener attached.

**Pros**
* Continuous discovery with always up to date value of available 
property.

**Cons**
* Difficult to stop discovery. If we want to stop it, then we have to 
remove all event listeners and then drop all the references to the 
instance of the `AvailabilityListener` interface. After that discovery
 can be stopped at the next pass of garbage collector (UA can optimize
 that though).
* If presentation screen discovered while promise to get listener is 
being resolved, the available will be set to true right after 
construction and `availablechange` event will never be fired. For API 
users that means that they will have to use both available property in
 addition to event listeners.

**Second proposal:**

```
partial interface NavigatorPresentation {
  AvailabilityListener listenForAvailability(…);
}

interface AvailabilityListener : EventTarget {
  Promise<boolean> getAvailability();
  attribute EventHandler onavailablechange;
}
```
Access to the interface is not behind the promise, but access to the 
`getAvailability()` is. Discovery runs when there is least one event 
handler on `onavailablechange` or request to `getAvailability()` is 
made and promise still unsolved.

**Pros**
* Continuous discovery happens only when event listener is attached.
* Single run discovery started when `getAvailability()` is called and 
stopped immediately after promise resolved.
* API user can use only one out of two API methods for different usage
 models; there is no need to use both (property and even listener) for
 continuous case. For continuous monitoring event will be always 
delivered at least once.
* Clear indication to the UA when discovery should be stopped (no 
event listeners attached), so better optimization can be applied.

**Cons**
* Boolean property value available is under promise, so access to it 
will take time (unless there is an event listener attached, then it 
resolved without waiting).


-- 
GitHub Notif of comment by obeletski
See 
https://github.com/w3c/presentation-api/issues/81#issuecomment-106292149

Received on Thursday, 28 May 2015 12:09:34 UTC