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

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.

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

Other ideas?

Thanks,

-Anssi

Received on Friday, 5 September 2014 11:12:52 UTC