Re: [battery] addEventListener side effects, ordering & boundary crossing of battery{low, critical}, window.on*

>>> I guess keeping stop() makes sense so that you do not need to rely on  
>>> garbage collection if you want to stop firing events. We'd still need  
>>> to specify what happens when GC kicks in (discard tasks queued etc.),  
>>> and in fact, invoking stop() would essentially do the same but act  
>>> consistently across browsers (AFAIK not all browsers use the same GC  
>>> algorithm).
>>>
>>
>> If the event listeners are unregistered, that would have similar side  
>> effects (user agent cleaning up what need to be).
>
> Are you suggesting there's no need for stop()?
>

If stop() exists solely to tell the user agent that no more events need to  
be dispatched, then doing removeEventListener can be handled the same way  
(and should be), just like suggested for addEventListener.  
addEventListener and removeEventListener aren't magic or too transparent  
like a GC. The user agent can tell if there is a listener or not and setup  
the proper system hooks, if need be. You can add a non normative hint for  
implementors.

>> On a general note, I do not understand well the need for  
>> baterrylow/critical events. Would be far simpler to just use level, and  
>> two extra properties in the event object like lowLevelThreshold,  
>> criticalLevelThreshold with the user agent's configured values. Then  
>> the app could just check the current level against the configured one.  
>> A suggestion to make it simpler.
>
> The current design is based on an assumption that firing too many  
> (unnecessary) events would be bad for performance.
>
> I am happy to revisit this issue and simplify the spec as you suggest if  
> shown real world evidence of the performance implications of firing a  
> large number of events.
>

The spec tells to fire an event when "level varies by a 1% or more".

Then what would be the frequency of a batterystatus event ? Once after  
registering the listener and then once every minute ? 5 minutes ? 10  
minutes ? The spec mentions 1%. If so, that seems hardly too many events  
in too little time. I doubt events will be dispatched every 100  
miliseconds telling the battery has been drained a tiny bit.

And a small nit pick
  - http://www.w3.org/TR/battery-status/#widl-BatteryStatusEvent-isPlugged
Perhaps isPlugged would be better named as isCharging. Or it should be  
isPluggedIn :)

Cheers.

Received on Monday, 5 September 2011 23:45:29 UTC