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

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