[battery] next steps and questions

Thanks Cathy and Tim for carefully reviewing the battery specification and Anssi and Mounir for the timely updates and discussion.

It seems that we have expanded the requirements by explicitly addressing multiple batteries and that is has raised questions and requires some new work. My sense is that this specification is not yet ready for LC, but maybe we are close enough that we can still publish, we will have to decide that once the discussion and changes settle down.

I must admit I’m confused - why is it correct to have the default attribute values emulate a fully charged battery? Shouldn’t the default values be ‘unknown’ until the state of the battery is determined and the values can be properly initialized?  I believe this requires more than a note, instead a new 2nd paragraph explanation in section 6 of this model.

I think Tim is correct, the section on multiple batteries (section 6.1) makes a number of assumptions on whether batteries charge/discharge in serial or parallel so the language and rules may not be correct in all implementations.  I suggest we make some of the language non-normative as I propose here (without the formatting):

[[

If a hosting device contains more than one battery, BatteryManager SHOULD expose an unified view of the batteries.

The charging attribute MUST be set to true if at least one battery's charging state as described above is true. Otherwise, it MUST be set to false.

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.

Depending on whether multiple batteries charge in parallel or serially, the chargingTime attribute can be set to the maximum or sum of the individual battery charging time, respectively.

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.

]]

Have all of Tim’s other comments (e.g with respect to calling updateTimer been addressed - I think so)

Thanks

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch



On Jun 9, 2014, at 5:09 PM, <cathy.chan@nokia.com> <cathy.chan@nokia.com> wrote:

>> From: ext Tim Volodine [mailto:timvolodine@google.com] 
>> 
>> a few more comments:
>> 
>> section 1, example 2:
>> An extra call to updateTimer(battery) once the promise resolves would probably be better. Otherwise the updateTimer is only called when the battery actually changes (and not at resolve time). This also applies to Examples 3 and 4.
>> 
>> section 5, the steps after getBattery() is invoked should mention the case when the getBattery() method is invoked for a second time while the first promise has not resolved yet. 
>> 
>> section 6, in the sentence: "When a BatteryManager object is created..." should say that "if the implementation is unable to report *any* battery information" the default values should be as stated.
>> 
> 
> I think this is where the confusion and my earlier comment comes in. If an implementation is able to report three of the attributes but not the last one, does it apply the default value of only the unavailable attribute, or does it apply the default values to *all* attributes? For instance, if an implementation knows the battery is discharging, but is unable to report the discharging time, does it leave charging as false and set dischargingTime to positive infinity (the former interpretation), or does it also have to set charging to true (the latter interpretation)?
> 
>> section 6.1, multiple batteries:
>> replace: must -> should
>> level -- should use a weighted average in case batteries have different capacities.
>> chargingTime -- depending on how the batteries are charged, sequentially or in parallel this could be either a "sum" or "max".
>> dischargingTime -- "max" if the batteries a discharging in parallel or a "sum" if in sequence (which is probably the more likely scenario).
> 
> I wonder how likely it is for a UA to be able to gathering information on the charging/discharging mechanism being used.
> 
> Additionally I begin to wonder how useful/necessary it is to specify how the attribute values are to be aggregated, especially if it'll only be a 'should' anyway. For one thing, I'm guessing that on some systems, despite the presence of multiple physical batteries, the UA might not be able to retrieve info on individual batteries from the system but would only be getting the aggregate info. In such cases, the UA has no control on whether these rules are followed (which dictates that these can only be 'should's). For another, these simple rules may not be able to capture all scenarios. The effort spent on fine-tuning the rules might not be worth it. So I think these should be given as examples on how to aggregate if the UA needs to do so, instead of as normative rules.
> 
> - Cathy.
> 
> 
>> thanks,
>> Tim
>> 
>> 
>> On Mon, Jun 9, 2014 at 3:12 PM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
>> On 09 Jun 2014, at 16:28, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
>> 
>>> I moved all the descriptive text into its own paragraph after the IDL block:
>>> 
>>> https://dvcs.w3.org/hg/dap/rev/65ff0151a2e5
>> I should have said *above* the IDL block. Here's a pointer to ease the review:
>> 
>> https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html#batterymanager-interface
>> 
>> Thanks,
>> 
>> -Anssi
>> 
>>

Received on Wednesday, 11 June 2014 15:08:02 UTC