On Thu, Jul 3, 2014 at 8:24 AM, Domenic Denicola < domenic@domenicdenicola.com> wrote: > From: Mounir Lamouri [mailto:mounir@lamouri.fr] > > > I don't think the requestFoo() model works very well for battery. The > API is defined in a way that if you did not get access to the battery for > the reasons listed above, we still RECOMMEND getBattery() to return a > BatteryManager with default values. > > Yes, I guess I was not clear. My original post was mainly about > questioning whether this is a good recommendation, instead of forcing > authors to handle the failure path. Thus "I realize that the default values > idea might have been a result of a previous discussion that I missed, and > would be happy to be pointed toward it." The name is not the important > part; indeed for back-compat and reduced churn I might imagine we want to > keep getBattery(). > If back-compat is a concern, then be concerned about changing from navigator.battery (a synchronous accessor, that behaves as synchronous hardware APIs should) to the unnecessarily async navigator.getBattery that doesn't get a BatteryManager, but instead a promise, that will in turn resolve to a BatteryManager. I have yet to see any compelling (or even informative) discussion that supports this change. The previously linked "CFC" was vague at best. Rick
Received on Thursday, 3 July 2014 18:21:09 UTC