Re: Ambient light API redesign

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