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

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