Should we align permissionState values with other APIs?

[clelland]

In #39, we've discussed the merits of sharing method names for the {get|has}Permission(Stat{e|us}?) method with the Push, Notification, and Permissions APIs.

Should we also be aligning the enum values values with those APIs? Push and Permissions both use granted, denied, and prompt, while Notifications and BackgroundSync have default, denied, and granted.

If we're eventually moving to the Permissions API, then maybe we should be using it's enums. I think that 'prompt' is useful to have, and makes more sense than default for BackgroundSync. ('default' is a nebulous concept anyway, and if the user agent reserves the right to change what the default behaviour is, then it doesn't tell the app developer anything at all. 'prompt' is at least explicit about what will happen.)

[wibblymat]

To reverse this, is there any good reason NOT to change it? What was the rationale for making it default in the first place?

[beverloo]

Please use prompt rather than default.

Notifications is the outlier here, but it's rather difficult to change the value given that multiple implementations shipped it already. Newer APIs have settled on prompt.

[KenjiBaheux]

+1 to converge on prompt (I don't remember seeing a rationale for default).

[domenic]

+1 to converge to default; I wish the Permissions API didn't fork the existing shipping APIs with its new name for things.

[clelland]

@domenic -- to be clear, your +1 is a dissenting opinion, right? To keep it as-is rather than align with Permissions?

[domenic]

@clelland yeah, as well as a vote for fixing Permissions. grumble grumble.

[annevk]

I also dislike the Permissions API forking precedent.

[jkarlin]

The one-shot spec has no permission status method. I suggest for one-shots that we keep it that way and if we need permission in the future we can use the Permissions API for it.