- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Fri, 08 Aug 2014 23:14:43 +1000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Device APIs Working Group <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Fri, 8 Aug 2014, at 19:31, Kostiainen, Anssi wrote: > To address this part of Domenic’s feedback, however, I suggest we revise > the following normative prose: > > [[ > > The user agent SHOULD NOT reject the promise returned by getBattery(). If > the user agent does not want to expose the battery information to the web > page, it is RECOMMENDED to not expose getBattery() or resolve the promise > with an instance of BatteryManager exposing only default values. > > ]] > > ... as follows: > > [[ > > The user agent MUST NOT reject the promise returned by getBattery(). If > the user agent does not want to expose the battery information to the web > page, it MUST resolve the promise with an instance of BatteryManager > exposing only default values. > > ]] > > I think it is implied that if the UA does not implement the spec, then > getBattery() is not exposed, thus "it is RECOMMENDED to not expose > getBattery()” seems redundant. > > Is a promise that cannot reject (IOW “the user agent MUST NOT reject the > promise ...”) a bad practice to be avoided at all cost? If so, then > s/MUST NOT/SHOULD NOT/ above, and in addition, we’d then need to add > prose to explain when it is appropriate to reject. > > All - please let me know if you have concerns with the above change. I’ll > update the Editor’s Draft if there are no concerns with this change. I > suggest we keep the "promise or not to promise" i.e. sync vs. async API > discussion in its own thread to stay focused. That changes looks good to me. -- Mounir
Received on Friday, 8 August 2014 13:15:15 UTC