Re: Battery Status API Last Call Feedback

added editorial comment as LC-2576 in last call comment tracker

https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-battery-status-20111129/2576

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group




On Nov 30, 2011, at 12:37 AM, ext Sergiu Dumitriu wrote:

>> 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 14:28:58 UTC