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

Re: DAP-ISSUE-168: getBattery() vs. requestBattery() pattern [Battery Status API]

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 08 Aug 2014 23:14:43 +1000
Message-Id: <1407503683.1902312.150565469.2C5A8BDA@webmail.messagingengine.com>
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

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