Push-api / HTML5-Notification Permissions

[millisecond]

If we have a case where a webapp wants to register for the push-api as spec'd here, and then display the notifications to the user using a HTML5 Notification style box, would the webapp have to request two separate permissions or is that "included" in the push-api permission request?

This seems like a fairly normal case, that would be nice not to bombard the user with multiple permission dialogs.

[nikhilm]

2 seperate permissions. The dialog is a UA issue and not spec detail.

Ideally the UA would be able to combine them since the calls are async. I imagine a pattern where the UA waits a turn of the event loop for the web-app to enumerate all its permission requests, then shows the dialog might work well. Some of the current permission request APIs (geoloc, Notification) are not Promise based, but imagine this.

Promise.all([
  Notification.requestPermission(), // Some shimmed form that returns a Promise
  navigator.push.hasPermission()
]).then(function(perms) {
  if (perms[0] == 'granted') { // notifications ok; }
  if (perms[1] == 'granted') { navigator.push.register(); }
});

[anssiko]

@nikhilm Have you been experimenting with the idea further?

There's related discussion over at SysApps (http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/0070.html), and the group is pondering whether to draft an API that would formalize the pattern, to be implemented by APIs that request permissions. Something along the lines of:

enum PermissionLevel {
  "default",
  "denied",
  "granted"
};

[NoInterfaceObject]
interface Permissions {
  Promise<PermissionLevel> requestPermission ();
  Promise<boolean> hasPermission ();
  /* ... */
};

Notification implements Permissions;
PushManager implements Permissions;
/* ... */
Geolocation implements Permissions;

WDYT?

[millisecond]

The solutions proposed by @anssiko or the Promise based one @nikhilm outlined sound very workable. Is that even conceivably implementable in the same time-frame though?

If it's not and one permission didn't imply the other, "push" and "notifications" would essentially be split along "spec lines" that would greatly limit the functionality that already exists in the marketplace as a single unit.

It's like if "push notifications" also required a network permission to operate (clearly not in the same spec, but also clearly required).

[nikhilm]

I haven't thought about this at all :) I'm not a spec guy, this was just what I came up with off the top of my head.

[anssiko]

@nikhilm I meant have you experimented with the idea in implementations (or have plans to)? Personally I feel this is a good proposal that would benefit from further experimentation in code.

As you probably know, the wider web community is currently looking at the permission solution space, and I feel this is good input to that discussion. I especially like the way how this could be retrofitted to many existing APIs without breaking backwards-compatibility. It would be too early to spec this feature yet though, we'd need feedback from implementers first.

Do you envision the Promise returned by requestPermission() to resolve with boolean (to indicate whether the request was granted or not), permission level of some sort (e.g. "default", "denied", "granted"), or something else? I updated the IDL sketch above to reflect the latter alternative.

[mounirlamouri]

I was pointed to this GH issue by Dave Raggett. I realise that you were sketching something close to what I proposed in public-webapps yesterday: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0389.html

Note that we are not including requestPermission() in this proposal (contrary to what was sketched here) and we decided to go for a single entry point API instead of a pattern. There are also slight differences, including the ability to specify options when checking for a permission.