W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2011

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

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Tue, 23 Aug 2011 14:06:25 +0300
CC: "public-device-apis@w3.org WG" <public-device-apis@w3.org>
Message-ID: <B4ACE156-A3CB-41D1-8A57-B1012CB0B020@nokia.com>
To: ext Francois Daoust <fd@w3.org>, Dominique Hazael-Massieux <dom@w3.org>

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:



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

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:49 UTC