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

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

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Thu, 3 Jul 2014 12:24:27 +0000
To: Mounir Lamouri <mounir@lamouri.fr>
CC: Domenic Denicola <domenic@domenicdenicola.com>, Rick Waldron <waldron.rick@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Alex Russell <slightlyoff@google.com>
Message-ID: <F51238CC-ED6B-4405-92B6-4DE22FA4E92C@intel.com>
On 03 Jul 2014, at 12:47, Mounir Lamouri <mounir@lamouri.fr> wrote:

> On Wed, 2 Jul 2014, at 07:23, Domenic Denicola wrote:
>>> 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   
>> Right; in general we are pretty much done with infobar-style permission
>> asks, as a platform. But we can still use the
>> requestAccessToX().then(gotAccess, didntGetAccess) style even if getting
>> access is not done as the result of an infobar. Perhaps you get access if
>> you declare the need in a manifest, or if you're transported over HTTPS,
>> or you get it by default but the user can toggle it off on a per-webpage
>> basis. The user-facing API can still be uniform.
> I don't think the requestFoo() model works very well for battery. The
> API is defined in a way that if you did not get access to the battery
> for the reasons listed above, we still RECOMMEND getBattery() to return
> a BatteryManager with default values.

I made a small editorial tweak to clarify this:



Received on Thursday, 3 July 2014 12:25:31 UTC

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