Re: Battery Status Event Spec

Hi Anssi,

Looking good so far.

One typical use case is that I leave my laptop plugged in to the mains. 
My understanding is that in the current proposal, if my battery was 
fully charged but I was still plugged in to a power source, 'isCharging' 
would be set to false.

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

So when plugged in, I'd get a single initial event. Subsequent events 
would then only fire if and when the device was unplugged from the power 
source (with one triggered immediately when that happens). Once the 
device is unplugged from a power source then that is the only time that 
a BatteryStatusEvent becomes meaningful anyway.

Inversely, when the device was plugged back in to a power source, an 
event would immediately fire, with level = 100 and timeRemaining = 
Infinity again.

Sound good?

- Rich


Anssi Kostiainen wrote:
> Hi,
>
> The Editor's Draft of the Battery Status Event Specification is at:
>
>    http://dev.w3.org/2009/dap/system-info/battery-status.html
>
> It builds on the initial draft [1] and addresses or takes a note of the issues identified so far [2]. All feedback is welcome.
>
> Below I address the comments received so far (thanks!). The proposed changes have been baked in to the Editor's Draft.
>
> On 31.3.2011, at 17.48, ext Robin Berjon wrote:
>
>> It is certainly true that timeRemaining is hard to calculate, and will necessarily fluctuate as the activities you perform on your computer change. I think that it should be optional (I don't think that all platforms support it) but that it should be exposed if available as it is even harder for an application to evaluate it than it is for the system.
>
>
> timeRemaining is now optional i.e. nullable.
>
> On 31.3.2011, at 16.37, ext Robin Berjon wrote:
>
>> Maybe the best thing would be to provide some guidelines, maybe as SHOULDs?
>>
>>    • UAs SHOULD dispatch an event when timeRemaining varies by a minute or more.
>>    • UAs SHOULD dispatch an event when isCharging or isBattery changes.
>>    • UAs SHOULD dispatch an event when level varies by a 1% or more.
>
>
> Added the SHOULDs.
>
> On 31.3.2011, at 1.02, ext Tran, Dzung D wrote:
>
>> Please proceed with your plans and check in to the same location as SysInfo API. Also, I would like to contribute if possible
>
> Thanks, feel free to contribute.
>
> -Anssi
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0122.html
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0143.html

Received on Wednesday, 6 April 2011 12:59:23 UTC