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

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