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

On Fri, Jul 4, 2014 at 8:02 AM, Tim Volodine <timvolodine@google.com> wrote:

> One of the reasons we want to avoid synchronous access to battery is
> because it's harder to implement efficiently. For example in chrome you
> would either need a synchronous IPC or fetch the data on startup and keep
> track of it at all times, neither of which seemed acceptable hence the
> asynchronous proposal.
>

FirefoxOS/gaia/etc. has been shipping the navigator.battery API since 2012.
I've been searching for reports that would support this claim based on
their implementation, but cannot find anything. (Tizen ships it as well,
but I have no experience there). On non-web platforms, eg. Android, iOS,
the Battery[Manager|Status] objects are synchronous and can be used with
observer and broadcaster patterns. With all respect, I find it hard to
believe and accept that the creation of the BatteryManager object (only one
ever) is of substantial burden. Presumably, if a device has a battery it
also _always_ knows the state of that battery—this has been my experience,
but perhaps chrome is expected to run on devices where this doesn't hold
true?

Simply put, the change from:

  navigator.battery

to:

  navigator.getBattery().then(function(battery) {
    ...
  });


...changes the API from good to bad and ignores the two years of
implementation experience that has accumulated for the latter. Perhaps
before this change is accepted, or even seriously considered, the existing
Candidate Recommendation specification can be implemented and studied.

Rick