- From: Josh Soref <jsoref@blackberry.com>
- Date: Wed, 11 Jun 2014 16:14:40 +0000
- To: W3C Device APIs WG <public-device-apis@w3.org>
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