Re: Battery API: threshold attribute proposal

On 11/09/2011 09:03 AM, Poussa, Sakari wrote:
>> I'm not entirely sure what wakeups mean here. Given that the UA will
>> always get the event from the platorm backend, the difference between
>> sending the event to the WebApp or not seems small if the WebApp is
>> careful with the event handling.
>
> I am not entirely sure how the UA event distribution works but the idea
> was that if one or more webapps will use the attribute the back does NOT
> need to send any events. Further, in some platforms it is possible to set
> the threshold to the firmware so the backend gets less wakeups.

Then, as soon as a BatteryManager consumer is interested in all 
levelchange from 1.0 to 0.0, the optimization becomes useless, right?

>> 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...

The conflict between a third-party library setting .thresholdLevel and 
an application setting the same attribute to another value doesn't seem 
like a bug in the app. That kind of situations could and should be 
avoided but that would create a too simple way to screw things up.
Generally speaking, this is the disadvantages in using a singleton 
object (ie. getting the BatteryManager instance in navigator.battery). 
Using |new BatteryManager()| to get an instance would fix that (but 
creates other problems).

>> 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.

I'm joining Robin here: there are thousands of ways for a badly 
implemented UA to kill your battery or make your user experience 
horrible. We should just assume those UAs will fix their mistakes 
because of market pressure or simply lost their users.

--
Mounir

Received on Wednesday, 9 November 2011 15:25:08 UTC