Re: Adding an asynchronous getter (Promise) for screen availability status (issue #11)

Anton,

Thanks for the clarification.  I see the utility of the null value now,
although from a API point of view I would lean towards a tri-value enum
such as {unknown, available, unavailable} where each value can be assigned
a well defined meaning and the enum can be extended if necessary.

m.


On Tue, Sep 9, 2014 at 7:46 AM, Anton Vayvod <avayvod@google.com> wrote:

> Hi Mark et al,
>
> I agree it would be the minimum API needed for the needs of the page but
> the problem is that firing an event without any state actually changed (if
> the UA knows about screens being available before the event listener is
> registered) is uncommon. I think we can easily go down the route of the
> property being null before any real data is available from the UA and then
> it being in sync with the onavailablechange event. In the best case, the
> property will be true upon the page load and the page will start its
> presentation as soon as it can.
>
> AFAIK, a similar approach is being considered for device sensors API:
> https://gist.github.com/rwaldron/5016343
>
> Anton.
>
>
>
> On Mon, Sep 8, 2014 at 11:52 PM, mark a. foltz <mfoltz@google.com> wrote:
>
>> Anton,
>>
>> When you mention "other Web APIs", I assume you're talking about cases
>> like the WebSocket API [1] where the page can construct a WebSocket object
>> and add a handler to onreadystatechange before yielding execution.  This
>> way there's no ambiguity between the property (readyState) and the event
>> (readystatechange).
>>
>> For the Presentation API, it's not clear what the initial value of the
>> property would be - we would have either leave it |null| or add an
>> "unknown" state.  And the page would probably assume that no screens were
>> available until it got an availablechange event telling it otherwise.  So
>> the property seems redundant, but maybe you can elaborate on:
>>
>> "We want, however, to avoid firing the event immediately with
>> e.available = true in case the UA already discovered some devices."
>>
>> Since I think that's exactly what we would want to do to minimize the
>> amount of time the user is unable to start presentation after page load.
>> m.
>>
>>
>>
>> On Fri, Sep 5, 2014 at 7:11 AM, Rottsches, Dominik <
>> dominik.rottsches@intel.com> wrote:
>>
>>> Hi Anton,
>>>
>>> On Fri, 2014-09-05 at 12:37 +0100, Anton Vayvod wrote:
>>> > We all agreed that the |onavaiablechange| event handler is the only
>>> > way to handle the fact that the device availability changes over time
>>> > otherwise we'd use a Promise for one time check. So we should assume
>>> > the page will add a handler to the |onavailablechange| as soon as it
>>> > wants to present something. We want, however, to avoid firing the
>>> > event immediately with e.available = true in case the UA already
>>> > discovered some devices. AFAIK, just because it's inconsistent with
>>> > all other event handlers.
>>> >
>>> > How would you see an async getter work along with the event handler?
>>> > Would the page get both the event from the event handler and an async
>>> > callback from the getter if the UA only started the discovery when the
>>> > event handler was added? I don't think we want to pass the same result
>>> > to the page twice.
>>>
>>> Agree with the summary - and not an easy question - I don't have an
>>> immediate answer, I think I need to research whether we can find a
>>> previously used paradigm from other Web APIs for this.
>>>
>>> Regarding your suggestion to have a cached "available" flag alongside -
>>> that would indeed be potentially confusing. If possible, let's try to
>>> avoid redundancy.
>>>
>>> Dominik
>>>
>>>
>>
>