

Re: Battery API: delay between events

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Wed, 2 Nov 2011 16:50:51 -0700
Cc: <public-device-status@w3.org>
Message-Id: <DA0C691D-3A2C-43D0-ABD0-BBEB81432EFF@nokia.com>
To: ext Mounir Lamouri <mounir@lamouri.fr>
On 1.11.2011, at 10.59, ext Mounir Lamouri wrote:

> I would like to do a proposal about the delay between chargingtimechange, dischargingtimechange and levelchange events. Indeed, I've seen in the specification a TODO note about chargingtimechange and dischargingtimechange events and how often they should be sent. This note should have applied to levelchange event because the current state of the specifications doesn't require a minimum change between two events (it was 1% before IIRC).
> In my opinion, the specification should not worry about that and should let the implementations send the events as often as they think it fits. The reason is that implementations will be based on platform backends and those backends are going to fetch battery information regularly (for example, upower on Linux does that every 30 seconds) but will do their best to not fetch information too often because it would have a bad impact on the battery life.
> Requesting to have a minimum change between two events of the same type would require UA to ignore some backend events and artificially reduce the precision.
> I see two cons for this proposal:
> 1. Sending an event as soon as there is an update from the backend is unlikely going to make the UA eating more CPU but we can't guarantee that consumers of this API are going to be cautious. If there is a levelchange event sent every 30 seconds and the webpage is nearly re-rendered at each levelchange events, sending them when there is a minimum amount of change would be better. I think we can consider that a minor issue because it should not be common to do a complex operation being done when there is a battery status change except for an app rendering a battery.
> 2. levelchange event listeners will always have to check for a delta1 change since the last event. Though, with the event being sent only if there is a change of delta2, it would have work only if both deltas are equals and if delta1 < delta2, it would have been just impossible...
> Feedback welcome :)

Mounir, many thanks for thinking this through!

I'd like to note that authors are always able to compare the value delta as well as the time delta between the events (using something like timeDelta = (new Date()).getTime() - prevTime) and do decisions based on that information, e.g. whether to throttle or not.

Given your reasoning above, I replaced the last remaining TODO in the spec with the following non-normative note:


The definition of how often the chargingtimechange, levelchange and dischargingtimechange events are fired is left to the implementation.


Let me know what you think, and feel free to suggest better wording.

Received on Wednesday, 2 November 2011 23:53:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 23:53:51 GMT