W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Battery Status API vs. Geolocation API

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 06 Jun 2011 12:28:43 +0200
To: Andres Riofrio <riofrios@gmail.com>
Cc: public-device-apis@w3.org
Message-ID: <1307356130.2519.344.camel@altostratustier>
Hello Andres,

The Battery Status API is deliverable of the Device APIs Working Group,
so I'm copying the group's list public-device-apis@w3.org.

(keeping public-webapps in BCC FYI)

Dom

Le dimanche 05 juin 2011 à 22:44 -0700, Andres Riofrio a écrit :
> I have some comments on the Battery Status API.
> 
> 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.
> 
> 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".
> 
> Andres Riofrio
> 
> 
> 
Received on Monday, 6 June 2011 10:28:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT