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

Rethinking availability monitoring

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Tue, 21 Apr 2015 13:53:27 +0000
To: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Message-ID: <37E15D54-82DB-42CB-B71C-5A878BFBD3E3@intel.com>
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.

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
Received on Tuesday, 21 April 2015 13:53:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 21 April 2015 13:53:59 UTC