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

Hi All, +Domenic

On 04 Aug 2014, at 22:38, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> DAP-ISSUE-168: getBattery() vs. requestBattery() pattern [Battery Status API]
> 
> http://www.w3.org/2009/dap/track/issues/168
> 
> Raised by: Frederick Hirsch
> On product: Battery Status API
> 
> on behalf of Domenic Denicola <domenic@domenicdenicola.com> 
> 
> http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0007.html
> 
> [[
> 
> The spec says
> 
>> 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.
> 
> I think there has been an increasing push to make APIs use a requestAccessToX().then(gotAccess, didntGetAccess) style. Alex, CC'ed, has some reasons why this is a good pattern in general; if I recall they are around how it enables a better permissions model for apps. (I hope he can explain better.)
> 
> But just from a consistency point of view, it would make more sense to me to converge.
> 
> 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.

Revisiting the thread, my interpretation is we do not have consensus to change the getBattery() semantics or the approach to the use of default values at this time. It appears the initial rationale for the design, especially to address the fingerprinting concerns as explained by Mounir at [1], is still valid.

> The "not expose getBattery()" part is kind of funny, as the spec is RECOMMENDing that implementations not comply with the spec :P
> 
> ]]

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.

Thanks,

-Anssi

[1] http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0035.html

Received on Friday, 8 August 2014 09:32:26 UTC