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

Re: [battery] Should getBattery() always return the same promise?

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 04 Jul 2014 19:03:37 +1000
Message-Id: <1404464617.6304.138019665.1FD3D33F@webmail.messagingengine.com>
To: Domenic Denicola <domenic@domenicdenicola.com>, Rick Waldron <waldron.rick@gmail.com>
Cc: "public-device-apis" <public-device-apis@w3.org>
On Wed, 2 Jul 2014, at 07:27, Domenic Denicola wrote:
> From: Rick Waldron <waldron.rick@gmail.com>
> > Is there a design history document or thread that explains the reasoning that lead to an API that returns a promise here? The battery exists before the browser ever loads a site and its JavaScript files, so why does `getBattery` need to be a promise?
> This is a great point, and a non-normative note would be helpful. My
> assumption was that it was so you could lazy-load battery-related code,
> or perhaps that battery information is stored out of process and thus
> some asynchronous prep-work must be done to make it available. I have no
> idea though and some help from implementers would be great.

As far as I am concerned, getBattery doesn't need to be a promise. This
is why the original specification was a property. The reason was that it
would be possible for the UA to do the work you mentioned. However,
implementers (in that case Google) expressed concerned that it was
adding a requirement on the UA that wasn't future-proof. In other words,
some UA might have a design that would make this very hard to do if
doable. Google proposed the change, Mozilla agreed.

-- Mounir
Received on Friday, 4 July 2014 09:04:05 UTC

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