W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2014

Re: Ambient light API redesign

From: Tobie Langel <tobie.langel@gmail.com>
Date: Mon, 8 Sep 2014 13:24:36 +0200
Message-ID: <CAMK=o4eoLc3ZLT3MEQdOiTdQH9b=d1tvUJPHFAaWc7pkPWy6Dg@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: Rick Waldron <waldron.rick@gmail.com>, Tim Volodine <timvolodine@google.com>, 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 Mon, Sep 8, 2014 at 11:56 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> I think the proposal above would be better than having sensor.value
> sometimes returning null because it would at least be consistent as far
> as web developers are concerned. However, there is no direct synchronous
> access to the value.
> I think Tim's proposal is less elegant (ie. getDeviceOrientationSensor()
> is less elegant than new DeviceOrientationSensor()) but it solves all
> the requirements: it is an asynchronous API that is easy to use for
> developers because after it is initialized, they have direct access to
> the value.
> I would consider the cosmetic issue less important than developer
> friendliness.

Given the requestAnimationFrame use cases exposed by Rick, it seems that
obtaining the Sensor instance immediately is more developer friendly than
getting it through a resolved promise. Especially if numerous sensors need
to interact.

That said, only concrete examples (i.e. code) will allow choosing one API
over the other.

Also, keep in mind that there's always the promised base static API for

Received on Monday, 8 September 2014 11:25:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:12 UTC