Re: Battery API: threshold attribute proposal

Hi,

Seems that the threshold attribute does not receive too much support to be
added to the spec.

I'll propose we'll drop the request and close the issue.

-sakari

On 11/9/11 7:24 AM, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>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 Monday, 14 November 2011 23:21:17 UTC