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

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

From: Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Mon, 04 Aug 2014 19:38:42 +0000
Message-Id: <E1XEO5i-00031r-Nj@shauna.w3.org>
To: public-device-apis@w3.org
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. The "not expose getBattery()" part is kind of funny, as the spec is RECOMMENDing that implementations not comply with the spec :P

]]
Received on Monday, 4 August 2014 19:38:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC