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

Hi,

On 2.9.2011, at 12.35, ext Anne van Kesteren wrote:

> On Thu, 01 Sep 2011 14:19:30 +0200, Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote:
>> All - Would you like the working group to make progress based on this alternative proposal instead of the current Editor's Draft? Any comments, bug fixes etc. are welcome.
> 
> 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).

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.

-Anssi

Received on Friday, 2 September 2011 10:56:39 UTC