- 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
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 UTC