- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 9 Nov 2011 10:31:37 +0100
- To: "Poussa, Sakari" <sakari.poussa@intel.com>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, "public-device-status@w3.org" <public-device-status@w3.org>
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