RE: Battery Status Event Spec

Anssi,

Thanks for the response 

> This means we have to do some re-thinking, and we can not just simply split the existing spec into smaller pieces and be done with it.

Yes right, I don't mean just blindly split without re-thinking.

> I propose we align with the model used by the DeviceOrientation and add an interval attribute to the BatteryStatusEvent: "The event must fire at regular intervals and the interval must be reported, in milliseconds, using the interval attribute of the BatteryStatusEvent object."

One concern is that I don't particular think that firing events on regular intervals make sense for Battery status. It makes sense for DeviceOrientation, since the use case is different in a sense that you want to update the map on regular interval. As for battery, you might just want to get an event when you are at a certain threshold such as 20% of battery left, unless you have a web app that display the battery meter, but how useful is a battery meter app.

Also I don't particular like the use of timeRemaining. Maybe it should be percentage charged?

> I volunteered to create an Editor's Draft based on my initial input and factor in the above changes. Are you ok with me proceeding with that? I'm fine if you want to proceed with editing the remaining parts of the SysInfo API. Also, if you want to co-edit the Battery Status let me know so that we can coordinate.

Please proceed with your plans and check in to the same location as SysInfo API. Also, I would like to contribute if possible

Thanks
Dzung Tran

-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
Sent: Wednesday, March 30, 2011 10:03 AM
To: Tran, Dzung D
Cc: public-device-apis@w3.org Group WG
Subject: Re: Battery Status Event Spec

Hi,

On 30.3.2011, at 18.23, ext Tran, Dzung D wrote:

> As I reviewed the SysInfo APIs section on battery status, since I was the editor for this and I don't see much differences here. I rather that we just start with what we have in the SysInfo APIs. I could do this easily for this and all the others into mini specs.

My proposal was to take the Power properties of SysInfo API as a starting point (because they're probably fairly well thought out) but apply them to the DOM Events -based model instead. The main benefits of the DOM Events-based model are re-usability and better integration to the web platform. This means we have to do some re-thinking, and we can not just simply split the existing spec into smaller pieces and be done with it.

We reviewed the proposed Battery Status Event spec during today's call and concluded it's good enough for an Editor's Draft. Here's a list of changes that we agreed to do:

1) Guarantee that the callback is triggered immediately upon handler registration.

Resolution: Add prose to make this a MUST.

2) BatteryStatusEvent should not be limited to applying to window.

Resolution: Allow any object to implement the BatteryStatusEvent interface. E.g. if AcmeCamera has its own battery that we may want to monitor separately: AcmeCamera implements BatteryStatusEvent.

3) If there's a change in battery status, what is the granularity of a change?

Proposal: Come up with a reasonable default that is good enough for all the Power properties. The timeRemaining and isCharging properties are probably the ones requiring the finest granularity. Perhaps the resolution of say 1000 ms would be enough for all the Power properties for majority of the high value use cases? I propose we align with the model used by the DeviceOrientation and add an interval attribute to the BatteryStatusEvent: "The event must fire at regular intervals and the interval must be reported, in milliseconds, using the interval attribute of the BatteryStatusEvent object."

I volunteered to create an Editor's Draft based on my initial input and factor in the above changes. Are you ok with me proceeding with that? I'm fine if you want to proceed with editing the remaining parts of the SysInfo API. Also, if you want to co-edit the Battery Status let me know so that we can coordinate.

-Anssi

Received on Wednesday, 30 March 2011 22:03:34 UTC