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

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

From: Rick Waldron <waldron.rick@gmail.com>
Date: Tue, 1 Jul 2014 17:18:56 -0400
Message-ID: <CAHfnhfokmqPZKEW8QHqa17E6C7LXFLB8s2TP423Re-W=2+0eBg@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, Alex Russell <slightlyoff@google.com>
On Tue, Jul 1, 2014 at 4:54 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> 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
>

The Battery Status API doesn't require user permission to access the
battery:
https://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html#security-and-privacy-considerations



Rick
Received on Tuesday, 1 July 2014 21:19:42 UTC

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