Re: [battery] status attribute, battery{low|critical|ok} event types ACTION-426 (was: ISSUE-114)

Hi,

On 18.8.2011, at 11.19, ext Francois Daoust wrote:

> On 08/18/2011 09:45 AM, Dominique Hazael-Massieux wrote:
>> Le mercredi 17 août 2011 à 22:10 +0200, Francois Daoust a écrit :
>>>> This means that if you're only interested in the "critical" state, you
>>>> would end up getting a lot more events than you need (and thus
>>>> ironically, drain the battery more than you need).
>>> 
>>> How much more is a "lot more" though? It seems we're talking about a
>>> hundred events or so that would get fired over a period of several
>>> hours. Even if it's within an hour, that does not sound like a lot of
>>> overhead.
>> 
>> Well, the number of events likely would depend on the rate of battery
>> usage, and again, the higher it gets, the higher the number of events.
>> 
>> Each event creates an interruption in the event loop, which wakes up the
>> processor if it was idle, etc, so I really don't think we should go in a
>> direction that would fire more events that needed for something that is
>> supposed to help control battery usage.
> 
> If raising 100 events in a "short" amount of time is a concern, the spec could perhaps add a throttling condition, e.g.:
> "level changes by at least 1 and previous event fired more than a minute ago"
> ... but that sounds like something that could be left to implementations (there is no requirement for user agent to check battery level every xx seconds AFAICT)

I thought about this a bit more and came up with the following design:

  http://dev.w3.org/2009/dap/system-info/battery-status.html
  
Changes:

  http://dev.w3.org/cvsweb/2009/dap/system-info/battery-status.html.diff?r1=1.34;r2=1.35;f=h

* Added the status attribute to the BatteryStatusEvent interface as proposed by Francois.

* Added a new event type batteryok. The values of the status attribute (low, critical, ok) now have corresponding battery{low|critical|ok} event types.

With these changes, developers are able to:

i) listen to the batterystatus events to get isPlugged, level and status if they're not worried about getting too many events, or

ii) listen to the battery{low|critical|ok} events if they are concerned of performance and wish to only get the minimal number of events.

I believe this addresses all the high-value use cases we've discussed so far, while not adding much in terms of complexity. Let me know what you think.

-Anssi

Received on Tuesday, 23 August 2011 11:17:57 UTC