Adding an asynchronous getter (Promise) for screen availability status (issue #11) from Kostiainen, Anssi on 2014-09-05 (public-webscreens@w3.org from September 2014)

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 5 Sep 2014 07:47:22 +0000
To: Anton Vayvod <avayvod@google.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Message-ID: <07C7B2FC-768D-4E3F-B34B-008B5F6DB7AA@intel.com>

[+public-webscreens]

[Relaying the comment Anton made on GitHub [1] to the public-webscreens mailing list. This is to test drive the workflow proposed by MarkFo [2] where we have the technical discussion on the public-webscreens mailing list and only record the resolution of issues in GH when consensus has been reached.]

In [1] Anton commented:

On 04 Sep 2014, at 16:59, avayvod <notifications@github.com> wrote:

> Why can't we just have an "available" property to match the event? This seems to be the consistent thing with other APIs.

I believe that as long as we define an “unknown" state too, that’d work. A boolean may not be able to convey enough information in this case, given we’d probably like to make a distinction between “not available” and “don’t know yet”. Something like:

enum AvailableState { “unknown", “available", “unavailable" };

interface NavigatorPresentation : EventTarget {
  readonly attribute PresentationSession? session;
  PresentationSession requestSession(DOMString url);
  attribute AvailableState availablestate;
  attribute EventHandler onavailablechange;
};

Are there implementability concerns in keeping the availablestate in sync? On the presenting page availablestate would always be “available”.

Thanks,

-Anssi

[1] https://github.com/webscreens/presentation-api/issues/11
[2] http://lists.w3.org/Archives/Public/public-webscreens/2014Sep/0005.html

Received on Friday, 5 September 2014 07:48:47 UTC