W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Rethinking availability monitoring

From: Oleg Beletski via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 May 2015 12:09:29 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-106292149-1432814968-sysbot+gh@w3.org>
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.

* Continuous discovery with always up to date value of available 

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

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

* 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
Received on Thursday, 28 May 2015 12:09:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 May 2015 12:09:34 UTC