Re: [battery] next steps and questions

Josh

> We have found that the API is hazardous to battery life (consuming perhaps
> 1% of the battery per event?).
> 
> I suspect it'd be pretty easy to suggest an API based on a "battery low"
> (promise).
> 
> Roughly: GetBattery().isBatteryLow().then()
> With no other exposed bits.

Thanks for outlining the general nature of the concern, as well as suggesting a proposal,  that is very helpful.

Implementers and WG members, do you have feedback on both the concern (e.g. do you have facts/experience that help) and the proposal Josh suggested?

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch



On Jun 11, 2014, at 12:14 PM, Josh Soref <jsoref@blackberry.com> wrote:

> Marcos wrote:
> 
>> Surely you mean, "we found some ways that the API could be potentially
>> improved... and we are excited to share that with the WG" :)
> 
> Nope.
> 
> We have found that the API is hazardous to battery life (consuming perhaps
> 1% of the battery per event?).
> I'm not in a good position to offer a way to improve it (the naïve
> suggestion is "retire the proposal").
> 
> Can someone please provide a handy link to the UC/Req document (so that
> the Cordova people can review it)?
> 
> It's hard to provide suggestions without this.
> 
> I suspect it'd be pretty easy to suggest an API based on a "battery low"
> (promise).
> 
> Roughly: GetBattery().isBatteryLow().then()
> With no other exposed bits.
> 
> I can provide some additional feedback about "charging" (possibly similar
> to feedback I gave while wearing a Nokia hat):
> It's very easy to end up in a state where a phone is attached to a
> computer, and is thus only allowed to draw 500mA, and due to the way the
> system works, it would need 512mA before it could consider itself
> "charging" (the step below 512mA is something like 384mA (?), and is
> insufficient to be charging), however per USB spec, you aren't allowed to
> draw 512mA, and thus such a phone wouldn't be charging even if it's
> plugged into a computer (the 384mA or whatever number is iiuc lower than
> the amount normally used on some device). This certainly argues against
> offering a GetBattery().isPluggedIn().then() because that will easily lead
> to misleading information.
> 
> I suppose that GetBattery().isCharging().then() could be provided, afaiu
> that isn't particularly horrible. But, again, w/o access to the UC/Req
> document, it's unclear that this is worth even exposing.
> 
>> Be great of instead of flushing out some detailed feedback
> 
> Actually. No. Please stop saying this.
> 
> Your goal should be to encourage people to speak up and represent
> themselves on the list. If you instead harass a proxy for information that
> the proxy doesn't have/isn't in a good position to provide, you're going
> to discourage people from providing the feedback that you want, and you
> won't get it/any.
> 
> So please, please, please, stop using this as a standard response.
> 
>> you can just provide a quick list of improvements for the group to
>> consider now.
> 
>> There is already talk of making the API promise-based, which might make
>> some things better.
> 
> A promise-based API would probably be a necessary step (the bits I've
> outlined above are certainly promise-based), but the bigger problems are
> anything that wants incremental bits/any level of monitoring, because that
> monitoring is expensive.
> 
>> Are there other concerns that you have? How does it currently fail to
>> address the needs of Cordova devs?
> 
> I'll let them speak for themselves.
> 
> The only additional concern I have is that the Cordova folks are running
> into the problems I tried to raise when the proposal was first made, and I
> was ignored.
>

Received on Wednesday, 11 June 2014 16:25:00 UTC