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

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

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Thu, 03 Jul 2014 23:51:59 +1000
Message-Id: <1404395519.18151.137711533.4B4A6E34@webmail.messagingengine.com>
To: Domenic Denicola <domenic@domenicdenicola.com>, Rick Waldron <waldron.rick@gmail.com>
Cc: public-device-apis@w3.org, Alex Russell <slightlyoff@google.com>
On Thu, 3 Jul 2014, at 22:24, Domenic Denicola 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().
> All that said, it's still worrying that the spec has RECOMMENDations
> instead of MUSTs for what seems like a key requirement for interop.
> Whichever is decided---default dummy battery, or failure path---IMO the
> spec should mandate one (and certainly not RECOMMEND omitting getBattery
> entirely).

The reasons were various. One is convenience. When the property was
synchronously accessible, having to check if navigator containing the
field battery could have been tiring. Another issue that this mitigates
is fingerprinting: whether you use a desktop, a fully charged laptop or
the UA doesn't want to reveal the battery information, the author will
get the same values. That mitigate the fingerprinting as much as we can
without having to go trough a permission prompt hell.

That's the approach we took when we designed this API, quite a long time
ago. Time has past and some concerns might no longer applied or be
considered as important as they used to.

-- Mounir
Received on Thursday, 3 July 2014 13:52:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:10 UTC