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

Rick, Chromium has a multi-process architecture, whereas Firefox in general keeps most things in a single process. Thus Firefox has the ability to implement many more things synchronously than Chromium does. Implementation experience based on a single vendor is not terribly valuable in guiding API surface, especially in questions of sync vs. async, and especially when that vendor is Firefox (the only single-process modern browser, from what I understand).

From: Rick Waldron<mailto:waldron.rick@gmail.com>
Sent: ?Friday?, ?July? ?4?, ?2014 ?11?:?43
To: Tim Volodine<mailto:timvolodine@google.com>
Cc: Mounir Lamouri<mailto:mounir@lamouri.fr>, Domenic Denicola<mailto:domenic@domenicdenicola.com>, public-device-apis<mailto:public-device-apis@w3.org>




On Fri, Jul 4, 2014 at 8:02 AM, Tim Volodine <timvolodine@google.com<mailto: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