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 13:49:56 -0400
Message-ID: <CAHfnhfpEr9i05_RvnuGCRMTRECmu-n55p5_vOFbb4zu2pvP9Hw@mail.gmail.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, 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 7:46 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> On 26 Aug 2014, at 12:43, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> > In https://bugzilla.mozilla.org/show_bug.cgi?id=1057185 we discovered
> > that the current API for  ambient lights is lacking and would require
> > hacks to addEventListener() to salvage. Since the API is not widely
> > adopted (only by Firefox per caniuse) we'd rather come up with a
> > better solution. Perhaps even establishing a pattern for how we should
> > expose hardware sensors to the web.
> >
> > Perhaps something like this:
> >
> >  var as = new AmbientSensor()
> >  var currentVal = await as.value
> >  as.onvaluechange = ...
> >
> > as long as you have a reference to the object or the object has a
> > listener attached it cannot be GC'd.
>
> Anne - thanks for the concrete proposal. IIRC we had a similar proposal on
> the table in the past (perhaps from Rick?),


Yes. https://gist.github.com/rwaldron/4502827

Rick



> but at that time we did not have async ES sugar, thus good to revisit this
> discussion.
>
> How far are we in terms of getting the needed language-level improvements
> in ES? I guess await and friends is a ES7 feature?
>
> Personally I think we should try to improve the API along the lines of
> Anne’s proposal, which is more forward-looking and fixes the known issue.
> 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.
>
> 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.
>
> Thanks,
>
> -Anssi
Received on Tuesday, 26 August 2014 17:50:46 UTC

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