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: Wed, 9 Nov 2011 08:03:20 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "public-device-status@w3.org" <public-device-status@w3.org>
Message-ID: <CADF6FF8.E345%sakari.poussa@intel.com>
On 11/8/11 2:27 AM, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>On 11/08/2011 07:31 AM, Poussa, Sakari wrote:
>> Background: During the F2F it was raised as a concern that the Battery
>>API
>> does not have the dedicated low and critical events anymore. Instead,
>>the
>> level and other events comes in on unspecified (implementation
>>dependent)
>> rate. Finally, there was no way for WebApp to be a good power management
>> citizen by limiting the number (wakeup) events it was consuming. On
>> battery powered devices (e.g. phones), every wake-up counts. The less
>> wake-ups you have the better you battery life is.
>
>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.


>Does it really make a difference if the
>UA gets informed about a change but doesn't send a DOM event to the
>WebApp?

No it does not. But see my previous comment above.

>In addition, the WebApp is able to cleverly handle the power management
>by not listening to the battery events when in the background for
>example (using the Visibility API).

True. But the app needs extra logic to do that. And foreground app still
gets them need it or not.

>
>> Proposal: the discussed solution was to define a 'threshold' parameter.
>> When set, the API doesn't level events if the battery level is above the
>> threshold. This way the WebApp can specify when it starts to receive
>> battery events. When not set, the events will behave like now (without
>>the
>> threshold parameter).
>
>If I understand correctly, this proposal is equals to:
>navigator.battery.addEventListener("levelchange", function() {
>   if (navigator.battery.level > THRESHOLD) {
>     return;
>   }
>   /* do stuff */
>});

In theory yes, but you don't save any wakeups with this solution.

>
>It seems that this proposal is solving only partially the problem you
>mentioned: if I understand it correctly, when the level is below the
>threshold value, the events will still be sent at the implementation rate.

Yes, you understood it 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...

>
>> attribute levelThreshold : When set (scale 0 - 1.0), indicates the level
>> threshold when the the system should start sending the 'onlevelchange'
>> events. When not set (equals to zero), the rate of the events is left to
>> implementation.
>
>FWIW, default value should be equivalent to 1.0. If 0.0 is set, no
>levelchange event should be sent.
>
>> Any comments?
>
>I do not think we should go with that proposal. It doesn't seem to fully
>solve the problem it tries to solve and it opens a door for bugs.
>In addition, this proposal only solves the issue of sending levelchange
>events. It doesn't take into account dischargingtimechange and
>chargingtimechange events which are actually the most complexes.

The time change events were left out intentionally. First, it complicates
things to have 3 thresholds. Second, the goal was achieved by subscribing
to level changes w/ threshold and once triggered the app can subscribe to
time change events.

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

-sakari


>
>--
>Mounir
>
Received on Wednesday, 9 November 2011 08:04:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 November 2011 08:04:20 GMT