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

Hi Anssi,

comments inline:

On Fri, Sep 5, 2014 at 12:11 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:
>
> Hi Anton, Dominik,
>
> On 05 Sep 2014, at 13:17, Rottsches, Dominik <dominik.rottsches@intel.com>
wrote:
>
> > On Fri, 2014-09-05 at 07:47 +0000, Kostiainen, Anssi wrote:
> >>> Why can't we just have an "available" property to match the event?
> >> This seems to be the consistent thing with other APIs.
> >
> > The reason why we might not want to have an available boolean is because
> > it might be associated with a cost to find out whether screens are
> > available. If you do a network discovery for screens, or reconfigure the
> > wireless radio to browse for screens, for power saving reasons it is
> > probably better to only do that on request. Also, because of network
> > latencies - the property's value is something that is not synchronously
> > available. In a way, the implementation behind the "available" is like
> > implementing a synchronous function.
> >
> > I would prefer an asynchronous getter for that reason - and would prefer
> > avoiding and "unknown" state - for which we would have to define
> > additional state transitions.
>
> Dominik - thanks for the explanation, the current design makes sense with
this background.
>
> I guess if we still want sync (personally not sure), we should in
addition provide a method to explicitly start the screen discovery
similarly to e.g. MessagePort’s start(), which would make the usage a bit
more clumsy.
>
> If we go down this path, I’m wondering if the API should allow stopping
the discovery too.


I think we should try to preserve the current semantics of the event
handler: the discovery may start (if not already started by another page)
when the event listener is added; the discovery may end when the event
listener is removed or the page is closed (since it won't listen to the
event anymore).

>
>
> Anton - wouldn't the sync availability cause similar issues in your
implementation?


I was thinking of the sync |available| property in a way of a cached
discovery state that's in sync with the event handler. It'd be unreliable
before the website adds an event listener since there's no way to get
updates on its state other than polling and it also won't trigger the
discovery. However, once the event listener is added, it becomes an easy
way to check if the page should wait for the event handler to fire an event
or not:

<button disabled>Show</button>
<script>
var presentation = navigator.presentation,
    showButton = document.querySelector('button');

presentation.onavailablechange = function(e) {
  showButton.disabled = !e.available; // presentation.available would be
the same as e.available here
};

showButton.onclick = show;
showButton.disabled = !presentation.available;
....
</script>

I realize that such caching behavior can also be confusing though the
concept is quite common in the software development (not sure about the Web
APIs though).

>
>
> Other ideas?
>
>
> Thanks,
>
> -Anssi
>