Re: Battery Status API Last Call Feedback

> The events need to be queued using the task queue defined in HTML5. It
> should probably be worded in such a way that the attribute is updated and
> the event is dispatched in the same task so nothing else can observe the
> attribute having changed before the event is dispatched.

Is this really needed? Normally, battery events should be rare, so the 
task queue should hold at most one event most of the time. However, 
let's assume that there's some heavy synchronous computation taking 
place that causes several battery events to be queued. When the queue is 
finally ready to be processed, a listener will suddenly receive a rapid 
burst of battery events.

If the events aren't tied to a particular state (as is the case in the 
current specification), then only one event would suffice, since the 
state doesn't change between the events.

If the events are tied to a state, it still doesn't make much sense IMHO 
to notify a listener that the battery went down to 16, 15 14% capacity, 
then the adapter has been plugged in, then the battery went up to 20%. 
This would cause the program to perform tasks that are not really 
needed, since the "real current" state is different than the one 
signaled by the event.

AFAICS, there's no mention in the HTML5 specification for emptying a 
task queue, but it would be useful IMHO to always maintain a queue with 
only one event. Any new battery event will replace the existing ones in 
the queue, and the reported state is always the current one, not that at 
the time of the event.

But this is not the proper place to discuss HTML5 models. Still, I'd say 
that the state reported by the BatteryManager should be the current 
state at all times, it shouldn't be bound to event dispatching.

> You also need to actually define the various on* attributes as being event
> handlers and update their IDL to match the latest crazy IDL syntax (which
> might be simplified, so maybe you want to wait for that).

Are the on* attributes needed? I never really liked on* attributes, 
given that they are so much limited compared to real event listeners 
added through the addEventListener method. Personally I'd remove them, 
and instead better define the events.


An extra editorial comment: in the BatteryManager interface, the level 
attribute should be listed after the dischargingTime attribute, to be in 
line with the order of their definition, and since it's a more logical 
order to keep charging and discharging time together.
-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Received on Wednesday, 30 November 2011 05:37:54 UTC