W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2011

Re: Battery Status API vs. Geolocation API

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 06 Jun 2011 06:38:56 -0400
Message-ID: <4DECAE40.5080007@nokia.com>
To: ext Andres Riofrio <riofrios@gmail.com>, public-device-apis <public-device-apis@w3.org>
[ 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:21 GMT