Re: [battery] Battery Editors Draft update needed to prepare for LC

Hi Cathy, Tim, Mounir, All,

On 10 Jun 2014, at 00:38, Cathy.Chan@nokia.com wrote:

>> From: ext Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
>> 
>> The defaults spec'd herein emulate fully charged battery. This means that
>> with these defaults, the experience is the same as if the device had full
>> battery.
>> 
> That's helpful in understanding the behaviors that are being specified. I think it's worth a note in the spec.

I added a note:

https://dvcs.w3.org/hg/dap/rev/e3adea99b9d6

>> Cathy - what are the clarification needed to support multiple batteries?
> 
> Let's say a system has two batteries, is unable to determine the status of one, and the other one is discharging. The aggregate battery would have
>   charging = true
>   chargingTime =  positive infinity
>   dischargingTime = positive infinity
>   level = avg(1.0, level of second battery)
> The aggregate chargingTime of positive infinity would match the definition of using positive infinity for unknown chargingTime, but not so much if unknown chargingTime is to be represented by 0. But since we have the catch-all "or otherwise" in using positive infinity for chargingTime, this might not be a big problem after all.
> 
> (Having said that, I'm in favor of not defining these aggregation rules at all. See http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0042.html).

I think it is fair to assume some platforms may want to implement this API even if they could only support a subset of the attributes (say, support charging and level, but not chargingTime and dischargingTime). Requiring an aggregate would mean we’d cripple such implementations as they’d fall back to defaults for all the attributes when the promise resolves, and only after the corresponding events fire they’d be able to report the real values.

Here’s an attempt to clarify this so that the attributes are not considered an aggregate:

https://dvcs.w3.org/hg/dap/rev/7476e089d3d9

[As always, we can revert if people have concerns.]

> One more comment:
> 
> [[
> The dischargingTime attribute MUST be set to the value positive Infinity, if the battery is charging, the implementation is unable to report the remaining discharging time, there is no battery attached to the system, or otherwise.
> ]]
> 
> What does "or otherwise" mean when it appears in the first sentence of a paragraph? "otherwise" of what? Does it pretty much mean the UA can use the value of positive infinity at its own discretion?

It means that anything else than a legit discharging time will be a positive Infinity. We can for example write a following statement:

if (battery.dischargingTime < Infinity) {
 // We know dischargingTime is a legit value.
}

Thanks,

-Anssi

Received on Tuesday, 10 June 2014 09:17:07 UTC