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. Tim On Fri, Jul 4, 2014 at 10:03 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > 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 12:03:20 UTC