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

> 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 Monday, 9 June 2014 21:09:40 UTC