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

Re: Ambient light API redesign

From: Rick Waldron <waldron.rick@gmail.com>
Date: Tue, 26 Aug 2014 15:34:58 -0400
Message-ID: <CAHfnhfouN3rahRdfvNUxnVVacLVzfhFKSdFxEh6z+WWB-fd_uw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, public-script-coord <public-script-coord@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Doug Turner <dougt@mozilla.com>
On Tue, Aug 26, 2014 at 8:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Aug 26, 2014 at 1:46 PM, Kostiainen, Anssi
> <anssi.kostiainen@intel.com> wrote:
> > How far are we in terms of getting the needed language-level
> improvements in ES? I guess await and friends is a ES7 feature?
>
> Well promises are here now. The synchronous syntax sugar will come
> later. I used it to show what the code will look like going forward.

Thinking about it some more it should probably be more something like
> getValue() as we want to return a new promise each time.
>
>
> > Also, this proposal supports N number of sensors of the same type (we
> can pass arguments to the constructor) -- something that the current API
> cannot do.
>
> I suspect we probably still want a constructor per sensor for ease of
> detection, but there could be a generic superclass.
>

As I've been saying since 2012:

- http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0060.html
- http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0024.html


The `await` example above is completely unnecessary. All of the sensor APIs
that I've been building and designing with have sync accessors for `value`
that simply produce the last reading reported (asynchronously) by whatever
device is being observed. Here's a simulation:
https://gist.github.com/rwaldron/5016343

Rick












>
>
> > Re Chromium/Blink implementation, an intent to implement was sent a
> while ago and the implementation is mostly done. However, the backend code
> should be reusable if we were to change the API.
> >
> > I’d be happy to update the spec if we hear no concerns, and work with
> our folks who are implementing to revise the implementation too.
> Process-wise, we’ve planning to go to CR, so should we move forward with
> this redesign, we should postpone not to confuse people.
>
> Sound good. Thanks for the quick reply!
>
>
> --
> http://annevankesteren.nl/
>
Received on Tuesday, 26 August 2014 19:35:48 UTC

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