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

Re: [battery] Moving Battery API forward, next steps?

From: <frederick.hirsch@nokia.com>
Date: Thu, 26 Jun 2014 18:33:16 +0000
To: <timvolodine@google.com>
CC: <frederick.hirsch@nokia.com>, <anssi.kostiainen@intel.com>, <public-device-apis@w3.org>, <ldeluca@us.ibm.com>
Message-ID: <99F10B42-E1C0-4C94-9E25-DA6027AAEC8E@nokia.com>
Tim

thanks for the additional concrete suggestions. Did the previous response from Anssi address your other concerns?

http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0070.html

see comments inline on your specific point

Thanks

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch



On Jun 26, 2014, at 1:57 PM, Tim Volodine <timvolodine@google.com<mailto:timvolodine@google.com>> wrote:

A few more comments on the current Battery Status API specification:

1. default value for chargingTime:

I think this has been raised in previous comments, but the default value for chargingTime is still unclear. I think the first paragraph about default values should look like:

"When the promise is resolved with the battery manager object and the implementation is unable to provide any battery information the default values should be as follows (which is equivalent to a fully charged battery):
charging=true, chargingTime=0, dischargingTime=Inf, level=1."

The "any" clause is important because in the paragraphs below the chargingTime is said to be +Inf if it cannot be provided by the implementation, which by the way makes more sense than 0 for platforms where this attribute cannot be provided (possibly temporarily).

We came to the same  conclusion on today’s teleconference, and I think your proposed language could improve the text.


2. multiple batteries:

level -- instead of "sum" of levels it should be "average”,

I believe the text we have addresses your suggestion: (in the updated editors draft, https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html )

"The level attribute can be set to the sum of the levels of batteries of same capacity, or the weighted average of the battery level attributes for batteries of different capacities.”


dischargingTime -- should be max dischargingTime if in parallel and sum if in series.

We did this as well

The dischargingTime attribute can be set to the sum or weighted average of the individual battery dischargingTime, depending on whether they discharge serially or in parallel respectively.



thanks,
Tim



On Mon, Jun 23, 2014 at 3:58 PM, <frederick.hirsch@nokia.com<mailto:frederick.hirsch@nokia.com>> wrote:
Anssi

I believe the following open items remain for the Battery API:

1. Proposed edit to new 2nd paragraph in section 6, http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0077.html<http://lists..w3.org/Archives/Public/public-device-apis/2014Jun/0077.html> (Frederick)

2. Follow up question/comment from Cathy http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0079.html

3. ACTION-699: Giridhar Mandyam to Review battery and how low battery threshold is handled

4.. Add warning to Battery API that (naive) implementation of API could negatively affect battery life

Tim,

I believe all of your comments have been addressed, see Anssi’s message: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0070.html

Can you please confirm or note any remaining issues?

Lisa

I believe Anssi addressed the various Cordova issues as noted in this email: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0068.html

Can you please confirm that there are no additional issues or concrete proposals for the Battery API from the Cordova community?

Giri, have you received any internal feedback related to your action?

Anssi

Are you aware of any additional open issues or questions related to the Battery API?  Can you please send a summary to the list? Also, if you are able to address any of the open issues I noted above before this Thursday’s DAP call, that would be helpful.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch
Received on Thursday, 26 June 2014 18:33:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC