Re: [battery] ISSUE-114

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.

This exchange makes me realize that I can read the "level changes by at least 1%" condition to fire a batterystatus event in two ways:
- 1% of the maximum value, which is 100. With that reading, there can be at most 100 events fired for a device going from battery full to battery depleted.
- 1% of the previous level. If that's how the spec should be read, I think that is potentially problematic, because more events could be fired when the battery comes close to depletion (if level is 1, then going down to 0,99 would be enough to meet the condition).

I suggest to clarify and adopt the first definition, yielding something like:
  "level changes by at least 1"
  (i.e. removing "%" since the scale is from 0 to 100)

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)


Received on Thursday, 18 August 2011 08:20:07 UTC