W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Ambient light API redesign

From: Rick Waldron <waldron.rick@gmail.com>
Date: Fri, 29 Aug 2014 10:10:03 -0400
Message-ID: <CAHfnhfpTo8_Lc3R3zpkLGV=BhJG9pw6FXEk-sN38aWZt7wq_Pw@mail.gmail.com>
To: Tobie Langel <tobie.langel@gmail.com>
Cc: Marcos Caceres <marcos@marcosc.com>, Jonas Sicking <jonas@sicking.cc>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Anssi Kostiainen <anssi.kostiainen@intel.com>, public-script-coord <public-script-coord@w3.org>, Doug Turner <dougt@mozilla.com>, Domenic Denicola <domenic@domenicdenicola.com>, Anne van Kesteren <annevk@annevk.nl>
On Fri, Aug 29, 2014 at 7:05 AM, Tobie Langel <tobie.langel@gmail.com>
wrote:

> On Tue, Aug 26, 2014 at 11:17 PM, Marcos Caceres <marcos@marcosc.com>
> wrote:
>
>> We are actually discussing this on Twitter right now. It seems you don't
>> need the promise. The constructor causes the subscription to the sensor,
>> and then you can potentially just observe `.value` until it gets updated.
>
>
> How do you handle permissioning with that model?
>

> More precisely, how do you handle cases when access is refused?
>

For the instances: "onerror" with an appropriately named event.type or
event.data

For the currentValue promise: reject and allow the program to handle the
rejected promise


>
> Should there be an onerror callback?
>

Yes


>
> Secondly, must the onchange event be called when .value is changed from
> null to its first value? Seems to be useful in a number of scenarios (e.g.
> do something with the first value and do it again whenever there's a value
> change).
>

Yes


Rick


>
> --tobie
>
>
Received on Friday, 29 August 2014 14:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC