- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Fri, 04 Jul 2014 19:03:37 +1000
- 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