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

Battery API: delay between events

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 01 Nov 2011 18:59:17 +0100
Message-ID: <4EB03375.3070702@lamouri.fr>
To: public-device-status@w3.org

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

Received on Tuesday, 1 November 2011 17:59:57 UTC

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