Re: Battery Status API vs. Geolocation API

Hi Andres,

On 6.6.2011, at 13.38, ext Arthur Barstow wrote:

> [ Bcc public-webapps; please reply to public-device-apis@w3.org ]
> 
> As noted in the Battery Status Event spec, comments for the spec should be sent to the DAP WG's mail list:
> 
> public-device-apis@w3.org <mailto:public-device-apis@w3.org>
> 
> On Jun/6/2011 1:44 AM, ext Andres Riofrio wrote:
>> Hello,
>> 
>> I have some comments on the Battery Status API.

Thanks for your comments.

>> I was wondering why it was that the battery status API is exposed
>> using Events (and adding an additional requirement "When an event
>> listener is registered with the event type batterystatus, then the
>> User Agent must dispatch a BatteryStatusEvent event immediately."),
>> when the Geolocation API is exposed using a getCurrent and a watch
>> function, that invoke a callback when the information is available. Is
>> there a rationale for using a different paradigm than the (kind of)
>> established Geolocation API? I think it'd be better (saner for
>> developers) to use the same paradigm.

The main reasons were reusability and better integration to the web platform. The event model allows registering listeners via addEventListener(), setting them via .onbatterystatus property, or by specifying onbatterystatus="..." attribute on the <window> tag in the HTML markup. This model should also work better for Workers (for example, an expensive algorithm running in a worker may want to check for the battery status).

Arguments against Geolocation-style API were e.g. no need for an error callback and sidestepping the too popular discussion on which object the API should hang off of :) We also tried the Geolocation-style API as part of the System Information API and it did not fly.

Also, there are Device Orientation events and online and offline events among others successfully using this model so we're not the first with this approach.

>> Further, doesn't the requirement that a BatteryStatusEvent be
>> dispatched immediately incur a synchronous delay as the browser gets
>> that information? That is, nothing else can happen because the event
>> must be dispatched immediately. I might understand wrongly, but if
>> this is the case, I think it should be changed to "retrieves the
>> relevant information and dispatches a BatteryStatusEvent
>> asynchronously".

Thanks, I clarified that part based on your feedback. See the latest Editor's Draft at:

  http://dev.w3.org/2009/dap/system-info/battery-status.html

... it refers to the DOM Level 3 Events spec and its definition of asynchronous events:

  http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#sync-async

As always, any additional comments are welcome!

-Anssi

Received on Monday, 6 June 2011 13:06:23 UTC