W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2014

Re: [battery] getBattery() vs. requestBattery() pattern

From: Rick Waldron <waldron.rick@gmail.com>
Date: Thu, 3 Jul 2014 14:20:22 -0400
Message-ID: <CAHfnhfrN+WHPGdPT2zv1b2bojh-KECVO6WTmKga=QtsPWWAN7Q@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Mounir Lamouri <mounir@lamouri.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Alex Russell <slightlyoff@google.com>
On Thu, Jul 3, 2014 at 8:24 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Mounir Lamouri [mailto:mounir@lamouri.fr]
>
> > I don't think the requestFoo() model works very well for battery. The
> API is defined in a way that if you did not get access to the battery for
> the reasons listed above, we still RECOMMEND getBattery() to return a
> BatteryManager with default values.
>
> Yes, I guess I was not clear. My original post was mainly about
> questioning whether this is a good recommendation, instead of forcing
> authors to handle the failure path. Thus "I realize that the default values
> idea might have been a result of a previous discussion that I missed, and
> would be happy to be pointed toward it." The name is not the important
> part; indeed for back-compat and reduced churn I might imagine we want to
> keep getBattery().
>

If back-compat is a concern, then be concerned about changing from
navigator.battery (a synchronous accessor, that behaves as synchronous
hardware APIs should) to the unnecessarily async navigator.getBattery that
doesn't get a BatteryManager, but instead a promise, that will in turn
resolve to a BatteryManager.

I have yet to see any compelling (or even informative) discussion that
supports this change. The previously linked "CFC" was vague at best.

Rick
Received on Thursday, 3 July 2014 18:21:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC