Re: Feedback about Battery Status Events

On 10/25/2011 10:59 AM, Anssi Kostiainen wrote:
> On 24.10.2011, at 18.30, ext Jonas Sicking wrote:
>
>> On Mon, Oct 24, 2011 at 1:41 AM, Mounir Lamouri<mounir@lamouri.fr>  wrote:
>>>
>>> I think 'remaining' should be used to show the remaining time before the
>>> battery is full when the battery is charging. This is an information UI are
>>> going to need.
>>
>> I'd rather use a separate property for that. That way it's easier to
>> write code which for example disables animations when there's less
>> than 10 minutes of battery time left.
>
> I renamed 'remaining' to 'remainingTime' and introduced a separate 'chargingTime' as per Jonas' suggestion:
>
> [[
>
> remainingTime of type double, readonly
>
> Represents the time remaining in seconds until the system's battery is depleted and the system is about to be suspended. The attributemust be set to the value positive Infinity, if the implementation is unable to report the time remaining, or there is no battery attached to the system.
>
> [...]
>
> chargingTime of type double, readonly
>
> Represents the time remaining in seconds until the system's battery is fully charged. The attribute must be set to 0, if the battery is full or not charging, or if the implementation is unable to report the remaining charging time, or there is no battery attached to the system.
>
> ]]
>
>    http://dev.w3.org/2009/dap/system-info/battery-status.html
>
> Let me know if there are any concerns with this change.

I do not really understand why having one property would make things 
harder. In both proposals, checking if there is less than 10 minutes 
left of battery would likely be:
if (!battery.charging && battery.remainingTime < 600) {
}

Except if .remainingTime returns Infinity when the battery is charging 
(it doesn't seem to be explicitly required right now but I guess that 
was the idea). In that case, having two attributes would allow blindly 
doing:
if (battery.remainingTime < 600) {
}

But adding |!battery.charging| doesn't seem like way harder.

Actually I worry about two things with having two attributes: 
duplication of information and wrong usage of one attribute.
For the former, it's just that having two attributes basically 
duplicates the idea of the battery being charging or not (basically, I 
could check if the battery is charging by doing battery.remainingTime 
=== Infinity).
For the later, For the later, I don't know if having one attribute would 
increase the chances of authors checking for the current state before 
using it. With two attributes, defaults values might fix that easily for 
.remainingTime but it's harder to find a sane default value for 
.chargingTime. Should it be 0 or Infinity when the battery is 
discharging? What authors would expect? (I think it should be Infinity FWIW)

Given that I'm pretty sure I'm not going to convince Jonas with so weak 
arguments, I would recommend two changes in the specs:
1. rename remainingTime to dischargingTime to make sure the name isn't 
confusing (it's too generic in my opinion);
2. chargingTime should return 0 only if fully charged and should return 
Infinity in all other situations (no battery and battery discharging).
(3. explicitly says that dischargingTime should return Infinity if the 
battery is charging)

--
Mounir

Received on Tuesday, 25 October 2011 11:01:34 UTC