W3C home > Mailing lists > Public > public-device-status@w3.org > November 2011

Re: Battery API: threshold attribute proposal

From: Robin Berjon <robin@berjon.com>
Date: Wed, 9 Nov 2011 10:31:37 +0100
Cc: Mounir Lamouri <mounir@lamouri.fr>, "public-device-status@w3.org" <public-device-status@w3.org>
Message-Id: <65CD85AB-73BA-4087-B030-FDD20DF953FC@berjon.com>
To: "Poussa, Sakari" <sakari.poussa@intel.com>
On Nov 9, 2011, at 09:03 , Poussa, Sakari wrote:
>> Furthermore, with this proposal, we are leading to conflicts between
>> multiple scripts in the same page which might set the threshold value to
>> different values. In addition of giving a false sensation of power
>> management efficiency to the WebApp, it might lead to bugs if the event
>> handler isn't ready to get values higher than the threshold.
> This sounds a bug in the app to me...

No, it's not. One of the usage scenarios is for JS libraries that do UI-related things to possibly modify the complexity of their animations when the battery is low. It would be very easy to have a library ask for a threshold and other code wanting a different one. If we do add a threshold, it needs to be defined without a global setting.

>> I think we should keep event sending rate as an implementation detail
>> because implementations can be careful and not send them too often. For
>> example, Gecko implementation on Android sends levelchange when there is
>> a 1% change and dischargingchange or chargingchange events are sent when
>> there is a levelchange or chargingchange events. Which make the events
>> being send not very often. FTR, it's actually an Android limitation and
>> we can't send those events more often if we use the public API.
> Yeah, maybe. This is not a super important functionality but it is bit
> worrisome that the app has no control over the rate it receive events.
> Gecko on Android might do well but other implementations could be worse.

Note that in general we shouldn't consider badly written user-agents an argument. If a UA is poorly written, then it will screw the user no matter what  in this case, it will be burning battery much faster in other places than the battery API :) We should assume decently well-written UAs, and if in that configuration we're still worried then we can look at either features such as this threshold, or a non-normative "Implementation Details" section that can point out pitfalls and suggestions.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 9 November 2011 09:31:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:59 UTC