Re: Battery Status Event Spec

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.

> The battery level and the fact that the device is connected to the mains seem to be two different pieces of information.

The proposal is for BatteryStatusEvent to provide only the current power 
source's status. That's only going to be relevant when the primary power 
source is a non-mains connected battery hence the proposal to only 
trigger events when in that mode of operation.

- Rich

>
> On Apr 6, 2011, at 8:58 AM, ext Rich Tibbett wrote:
>
>> 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 13:54:59 UTC