W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2014

RE: ISSUE-164: Correct default for charging time if unknown in battery (was: [battery] next steps and questions)

From: <cathy.chan@nokia.com>
Date: Tue, 1 Jul 2014 21:43:34 +0000
To: <anssi.kostiainen@intel.com>
CC: <public-device-apis@w3.org>, <mounir@lamouri.fr>
Message-ID: <ac700818712a450f9347dbbe4da5df0f@NOKWDCFIEXCH02P.nnok.nokia.com>
> -----Original Message-----
> From: ext Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> 
> On 26 Jun 2014, at 18:45, Cathy.Chan@nokia.com wrote:
> 
> > There are now three different places in the latest ED that talk about the
> value to use if the implementation is unable to report the value of
> chargingTime, all in Section 6 BatteryManager Interface
> (https://dvcs.w3.org/hg/dap/raw-
> file/e6ca4e6b30f8/battery/Overview.html#batterymanager-interface).
> >
> > [[
> > If the implementation is unable to report the battery status information for
> a particular attribute, the BatteryManager will emulate a fully charged
> battery by setting the attribute's value to a value that of the fully charged
> battery.
> > ]]
> >
> > [[
> > When a BatteryManager object is created, if the implementation is unable
> to report the battery's:
> >    charging state, the charging attribute MUST be set to true,
> >    charging time, the chargingTime MUST be set to 0,
> >    remaining time, the dischargingTime MUST be set to the value positive
> Infinity,
> >    level, the level attribute must be set to 1.0.
> > ]]
> >
> > [[
> > The chargingTime attribute MUST be set to 0, if the battery is full or there is
> no battery attached to the system, and to the value positive Infinity if the
> battery is discharging, the implementation is unable to report the remaining
> charging time while the battery is charging but not full, or otherwise.
> > ]]
> >
> > The first says that [at any time, I presume] if the implementation is unable
> to report the chargingTime, it is to be set to the value of a fully charged
> battery, i.e. 0. (By the way, that statement does not have a normative
> MUST.)
> >
> > The second says that *when a BatteryManager object is created*, if the
> implementation is unable to report the chargingTime, it MUST be set to 0.
> >
> > The third says that *while the battery is charging but not full*, if the
> implementation is unable to report the chargingTime, it MUST be set to
> positive Infinity.
> >
> > Obviously the last is inconsistent with the first. Since the first snippet was
> added by Anssi [1] after Mounir modified the third [2] to address one of my
> comments [3], we need Mounir's feedback on whether he agrees with the
> overall statement in the first snippet (in which case, the text in the third bit
> needs to be fixed).
> 
> I updated the spec as per Tim's and your feedback, which hopefully clarifies
> this.

Yep, that takes care of the inconsistency, which was my major concern.

We still have two paragraphs (above and below the WebIDL) that essentially describe the same thing:
[[
If the implementation is unable to report the battery status information for any of the attributes, the BatteryManager will emulate a fully charged battery by setting all the values to those corresponding values of a fully charged battery. The reason for using full battery defaults for unknown attribute values is that this will not cause applications to degrade performance or functionality by default if information is not available. It also reduces the potential for fingerprinting.
]]
[[
When the promise is resolved with the BatteryManager object and the implementation is unable to provide any battery information, the default values are set as follows (which is equivalent to a fully charged battery): charging MUST be set to true, chargingTime MUST be set to 0, dischargingTime MUST be set to positive Infinity, and level MUST be set to 1.0.
]]
Can we consolidate those into one paragraph, or is there some subtlety that I'm missing? Each time I read through that part of the spec, I found myself trying to figure out what the second paragraph is telling me that the first wasn't.

Also, with this latest edit, I think we can also s/the implementation is unable to report the remaining charging time while the battery is charging but not full/the implementation is unable to report the remaining charging time/ in the description of the chargingTime. That extra phrase ("while the battery is charging but not full") was added to address my previous feedback, but I think we don't need it anymore. Mounir, WDYT?

Regards, Cathy.

> 
> To summarise, the BatteryManager returned by the promise sets the
> chargingTime default to 0 along with other defaults to emulate full battery
> (note, after the latest update to the spec we're setting all of them together).
> Any subsequent updates to the chargingTime may set the value to +Infinity
> instead.
> 
> Reporting +Infinity at the later stage makes sense e.g. in this case:
> 
> if (chargingTime < 3600) {
>    // start an important operation that cannot be disturbed
>    doStuff();
> }
> 
> If we'd set the chargingTime to 0, doStuff() would be invoked erroneously.
> OTOH, if chargingTime would be set to +Infinity (as currently spec'd), that
> would not happen.
> 
> Please let us know if you have suggestions for further clarifications.
> 
> Thanks,
> 
> -Anssi
> 
> 
> > [1] https://dvcs.w3.org/hg/dap/rev/4c334400e0aa
> > [2] https://dvcs.w3.org/hg/dap/rev/a1f480a15e78
> > [3] http://lists.w3.org/Archives/Public/public-device-
> apis/2014Jun/0034.html
Received on Tuesday, 1 July 2014 21:44:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:10 UTC