Re: Ambient light API redesign

On Fri, Sep 5, 2014 at 10:18 AM, Tim Volodine <>

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

> Furthermore having a promise for value of high-frequency sensors does not
> seem efficient.

The static promise producing method should only be used for cases where the
application only needs to get the sensor value once without the need for
creating an instance that will be long-lived.

> Instead we could register once (using a promise) and then the data should
> be accessible 'synchronously' (with a possible sensor sampling delay of
> course).

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

  requestAnimationFrame(function frame() {

    // eventually, this will receive its first value reading and will
    // update every n milliseconds (based on frequency).
    if (light.value !== null) {

Having a promise also means we can reject it if the sensor is not
> available..

This is already covered by the one-time-and-done promise:
and the instance, via error event:


Received on Friday, 5 September 2014 15:00:28 UTC