- From: <Frederick.Hirsch@nokia.com>
- Date: Wed, 6 Apr 2011 13:36:37 +0000
- To: <richt@opera.com>
- CC: <Frederick.Hirsch@nokia.com>, <anssi.kostiainen@nokia.com>, <public-device-apis@w3.org>
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)? The battery level and the fact that the device is connected to the mains seem to be two different pieces of information. regards, Frederick Frederick Hirsch Nokia 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:37:42 UTC