Re: Battery Status Event Spec

Hi,

Thanks for the comments everyone, I try to address them below. Let me know if I missed something. The updated spec is here (a force refresh may be required):

  http://dev.w3.org/2009/dap/system-info/battery-status.html

In this draft, I added prose re onbatterystatus event handler and I also added some examples.

I believe we're ready for CfC if everyone's satisfied with the way how I handled your comments :)

On 7.4.2011, at 6.17, ext Tran, Dzung D wrote:

> Other thing is that do we want to mention something on handling multiple batteries such as an extra battery for my Lenovo T61, also iPhone have battery pack adapters. Maybe it is enough to mention that the battery's level could fluctuate due to hot plugged of extra battery pack.

Yes, the level/timeRemaining is based on all the batteries in the system. This is implied in the current prose, so feel free to propose an explicit wording.

On 6.4.2011, at 16.54, ext Rich Tibbett wrote:

> Frederick.Hirsch@nokia.com wrote:
>> Can't your battery be at 20% even when plugged into the power source,  and wouldn't it be useful to be able to know that (even when plugged in)?
> 
> Do you have a use case for this particular scenario?
> 
> The battery information only becomes critical once the device is unplugged from the mains. An event would then immediately fire, saying, for example "You've got 20% and 2580 seconds until power down". A web app could then respond accordingly to that information and a user could respond to however a web app manifests that information by plugging their device back in to the mains or e.g. wrapping up their session / saving their current progress.

How about this use cases: "Is it ok to unplug this device now and have x % or y mins left?"

if (event.isCharging && event.level > 50) {
  console.log('Unplug now and you have 50% left.');   
}

In implementation supporting timeRemaining, a more useful version would be:

if (event.isCharging && event.timeRemaining > 60*60) {
  console.log('Unplug now and you have about one hour left.'); 
}

On 6.4.2011, at 15.58, ext Rich Tibbett wrote:

> Rather than isBattery or isCharging, I'd prefer to remove these attributes. Instead we could change the spec to say that 'if the device is plugged in to a power source, the 'level' MUST be set to 100 and the timeRemaining MUST be set to Infinity'. If and when the device is unplugged, an event would fire, providing an updated timeRemaining attribute set to a non-Infinity value and an updated level attribute set to <= 100. For each subsequent move in those figures, a new event would fire (but when and how often should be left up to implementers).

With the above examples in my mind and my developer hat on I can think of additional cases where isCharging would simplify the code a bit, e.g.:

if (event.isCharging) {
  // we're charging
}

instead of:

if (event.level === 100 && event.timeRemaining === Infinity) {
  // we're charging
}

Functionally they're equivalent. So it's a matter of taste. But by dropping isCharging we would not be able to handle the two "Unplug now and ..." use cases described above.

For isBattery there's at least one use case I can think of:

if (event.isBattery) {
  // you're running on a battery so we'll disable the
  // power-hungry feature z to save the battery
  // (of course, you can enable z manually if you wish)
}

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).

-Anssi

Received on Thursday, 7 April 2011 13:36:31 UTC