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

Re: Battery API: threshold attribute proposal

From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
Date: Tue, 15 Nov 2011 09:38:29 +0100
To: "Poussa, Sakari" <sakari.poussa@intel.com>, Mounir Lamouri <mounir@lamouri.fr>, "public-device-status@w3.org" <public-device-status@w3.org>
Message-id: <CAE7E37E.1D953%jmcf@tid.es>
-1

In the F2F many of the participants requested this feature

El 15/11/11 00:20, "Poussa, Sakari" <sakari.poussa@intel.com> escribió:

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


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Received on Tuesday, 15 November 2011 08:39:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 November 2011 08:39:11 GMT