- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Tue, 23 Aug 2011 14:06:25 +0300
- To: ext Francois Daoust <fd@w3.org>, Dominique Hazael-Massieux <dom@w3.org>
- CC: "public-device-apis@w3.org WG" <public-device-apis@w3.org>
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