Re: Ambient light API redesign from Rick Waldron on 2014-09-01 (public-device-apis@w3.org from September 2014)

From: Rick Waldron <waldron.rick@gmail.com>
Date: Mon, 1 Sep 2014 14:45:22 -0400
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>
Message-ID: <CAHfnhfr_MkAQYwMqzX_qegSRtwCZAhvA3ygvnieNh6-zeN-dPA@mail.gmail.com>

On Fri, Aug 29, 2014 at 10:10 AM, Rick Waldron <waldron.rick@gmail.com>
wrote:

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

When applied to a Battery sensor, the word "current" becomes ambiguous, so
I've updated the proposal sketch to `requestValue()` (replacing
`currentValue()`). https://github.com/rwaldron/sensors

Rick

Received on Monday, 1 September 2014 18:46:10 UTC