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

On Tue, Jul 1, 2014 at 5:27 PM, Domenic Denicola <
domenic@domenicdenicola.com> 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 implemented in the latest stable Firefox, which is version 30,
navigator.battery has the appearance of a pre initialized
BatteryManager—though it may just be a synchronous accessor the produces
the BatteryManager on [[Get]].

The CFC that Mounir linked to says only this "This will allow for less
constrained and more efficient current and future implementations." and
doesn't provide any supporting cases for this claim. Furthermore, Marcos
Caceres mentions multiple batteries in a later message[0], a use case that
can't be addressed by this change anyway (which battery does
getBattery().then(...) resolve with???). Even multiple batteries exist
before the browser loads anything, so it's still unclear why the API needs
to be promise-based.

Rick





[0] http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0039.html