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

Re: Battery Status Event Spec

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Mon, 11 Apr 2011 16:00:50 +0300
CC: <public-device-apis@w3.org>
Message-ID: <B44F1766-838A-48A3-ADC6-9901D84AE573@nokia.com>
To: ext Suresh Chitturi <schitturi@rim.com>
Hi,

On 8.4.2011, at 22.10, ext Suresh Chitturi wrote:

> On 6.4.2011, at 16.46, ext Suresh Chitturi wrote:
> 
>> Thanks for the Editor's draft.
>> I like the approach here based off of the events model but wondering
> if
>> there should be an alternate way as well such as the one shot API.
>> The idea is specify a core interface with battery info that can be
> used
>> by event model and navigator implementations to allow for
>> flexibility/choice for implementations and developers.
> 
> 
> I added an example how to assign a function expression (aka anonymous
> function) to the onbatterystate property. It provides a simpler (in
> terms of loc) alternative. Do you think that would satisfy your concern
> re flexibility/choice?
> 
> My concern re exposing this information on navigator is that it makes
> the misuse easier (think using setInterval() with a 1 ms delay to poll
> the properties).
> 
> Suresh>> This alternative works for me Anssi, however, I was just
> looking for a way to minimize the event generation and let the
> developers poll for this info as needed...perhaps battery status change
> occurs too often compared some other properties.


I believe the events-based model is a better fit for the battery status for the reason you mention above. I will not include the navigator proposal in the spec at this point if you're fine with that. That said, we can re-evaluate your proposal later on if we find evidence that the events-based model does not cut it.

-Anssi
Received on Monday, 11 April 2011 13:00:57 GMT

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