Re: [battery] next steps and questions

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:15:10 UTC