Hi Mounir,
Have you considered making this return a promise, as per Nikhil's proposal:
https://github.com/w3c/push-api/issues/3#issuecomment-42997477
p.s. I will bring your idea to the trust & permissions in the open web
platform meeting, we're holding in Paris this week, see:
http://www.w3.org/2014/07/permissions/
Cheers,
Dave
On 02/09/14 14:51, Mounir Lamouri wrote:
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# Straw man proposal #
This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.
```
/* Note: WebIDL doesn’t allow partial enums so we might need to use a
DOMString
* instead. The idea is that new API could extend the enum and add their
own
* entry.
*/
enum PermissionName {
};
/* Note: the idea is that some APIs would extend this dictionary to add
some
* API-specific information like a “DOMString accuracy” for an
hypothetical
* geolocation api that would have different accuracy granularity.
*/
dictionary Permission {
required PermissionName name;
};
/* Note: the name doesn’t matter, not exposed. */
enum PermissionState {
// If the capability can be used without having to ask the user for a
yes/no
// question. In other words, if the developer can’t ask the user in
advance
// whether he/she wants the web page to access the feature. A feature
using a
// chooser UI is always ‘granted’.
“granted”,
// If the capability can’t be used at all and trying it will be a
no-op.
“denied”,
// If trying to use the capability will be followed by a question to
the user
// asking whether he/she wants to allow the web page to be granted the
// access and that question will no longer appear for the subsequent
calls if
// it was answered the first time.
“prompt”
};
dictionary PermissionStatus : Permission {
PermissionState status;
};
/* Note: the promises would be rejected iff the Permission isn’t known
or
* misformatted.
*/
interface PermissionManager {
Promise<PermissionStatus> has(Permission permission);
};
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorPermissions {
readonly attribute PermissionManager permissions;
};
Navigator implements NavigatorPermissions;
WorkerNavigator implements NavigatorPermissions;
```
The intent behind using dictionaries is to simplify the usage and
increase flexibility. It would be easy for an API to inherit from
Permission to define new properties. For example, a Bluetooth API could
have different permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
--
Dave Raggett <d...@w3.org> http://www.w3.org/People/Raggett
