Re: Battery Status API vs. Geolocation API

[ 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.
>
> 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:39:22 UTC