W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2014

RE: [battery] getBattery() vs. requestBattery() pattern

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 3 Jul 2014 12:24:39 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, Rick Waldron <waldron.rick@gmail.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, Alex Russell <slightlyoff@google.com>
Message-ID: <371b934fdfd54abd89895253da283860@BN1PR05MB325.namprd05.prod.outlook.com>
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().

All that said, it's still worrying that the spec has RECOMMENDations instead of MUSTs for what seems like a key requirement for interop. Whichever is decided---default dummy battery, or failure path---IMO the spec should mandate one (and certainly not RECOMMEND omitting getBattery entirely).
Received on Thursday, 3 July 2014 12:25:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:10 UTC