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

Re: Battery API: threshold attribute proposal

From: Poussa, Sakari <sakari.poussa@intel.com>
Date: Mon, 14 Nov 2011 23:20:46 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "public-device-status@w3.org" <public-device-status@w3.org>
Message-ID: <CAE6E206.E74C%sakari.poussa@intel.com>

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.


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
>> 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
>>> 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
>>> a 1% change and dischargingchange or chargingchange events are sent
>>> 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.
Received on Monday, 14 November 2011 23:21:17 UTC

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