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

Hi Joćo,

On 5.9.2011, at 0.42, ext Joćo Eiras wrote:

> On , Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote:
> 
>> HOn 2.9.2011, at 12.35, ext Anne van Kesteren wrote:
>> 
>>> If the events are dispatched asynchronously you do not need a start() method as far as I can tell. You can just start the events the moment you construct BatteryStatusEventSource(). Since they are dispatched from a task queue you should have time to add event listeners in the same task you construct the object.
>> 
>> Good point. That would simplify things and make the behavior between addEventListener() and onbattery* event handlers more consistent.
>> 
>> 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()?

>> There's one issue I can think of in dropping start() (and keeping stop()): if you stop() you'll need to construct a new BatteryStatusEventSource to continue firing. If we drop stop() too that would be more obvious, but there would be the GC issue mentioned above.
> 
> 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.

-Anssi

Received on Monday, 5 September 2011 11:19:03 UTC