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

Re: Ambient light API redesign

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Mon, 08 Sep 2014 19:40:26 +1000
Message-Id: <1410169226.3899460.164848409.20268DDF@webmail.messagingengine.com>
To: Rick Waldron <waldron.rick@gmail.com>, Tim Volodine <timvolodine@google.com>
Cc: Tobie Langel <tobie.langel@gmail.com>, Marcos Caceres <marcos@marcosc.com>, Jonas Sicking <jonas@sicking.cc>, 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 Sat, 6 Sep 2014, at 00:59, Rick Waldron wrote:
> On Fri, Sep 5, 2014 at 10:18 AM, Tim Volodine <timvolodine@google.com>
> wrote:
> 
> > "new Sensor.." does not sound natural in the context of sensors. There is
> > only one sensor per browser so it doesn't seem great to have multiple
> > objects for the same sensor.
> >
> 
> This is an assumption that will lead to problems in the future: devices
> are
> already shipping with more than one of certain sensors, eg. proximity
> sensor. Also, 1st and 3rd party code must be allowed to create their own
> references of sensor objects with specified reading frequencies—those
> instances might be deriving their values from the same hardware source,
> but
> the frequency of value delivery must be allowed to be application-domain
> specific.

Tim's proposal as much as yours can take that into account, it only
require to use a Dictionary in Tim's proposal and have frequency as one
known property. It would then be extensible.

> Replace "register once" with "initialize an instance" and you have the
> Sensor design:
> 
>   // use default frequency, whatever that might be
>   var light = new Sensor.AmbientLight();
> 
>   - or -
> 
>   // Specify a reading frequency in hz:
>   var light = new Sensor.AmbientLight({
>     frequency: 100
>   });
> 
>   // ...
> 
>   // synchronous access to the value, but this is null right now
>   // because the platform hasn't delivered a value yet...
>   light.value;

I think the main difference between the two approaches is here: you
create the sensor object synchronously then set the value asynchronously
while Tim creates the object asynchronously, thus never expose an
undefined value. I think Tim's approach is better because having
undefined value would be fairly hard to handle for the developer. An
alternative would be to not expose a synchronous getter but instead do
something like:
```
var sensor = new Sensor({ [...] });
sensor.getValue().then(function(value) {
  [...]
});
```
but that comes with the downside of requiring developers to keep track
of the current value themselves if they want to have a synchronous
access to it.

-- Mounir
Received on Monday, 8 September 2014 09:40:54 UTC

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