[w3c/permissions] Custom PermissionName definitions in other host environments (#212)

For an alternate host environment (seeking to be browser-compatible) which borrows the Permissions API, how would you advise extending the `PermissionName` enum with permissions specific to its domain?

---

In Deno, we borrow the Permissions API for powerful features not supported by browsers. We swap out the specified [`PermissionName`](https://www.w3.org/TR/permissions/#permission-registry) definition for the following:
```ts
enum PermissionName {
  "run",
  "read",
  "write",
  "net",
  "env",
  "plugin",
  "hrtime",
};
```

The problem is the spec has it's own concretely defined enum. We've dodged that by defining ours in [`Deno.permissions`](https://deno.land/manual/examples/permissions#inspecting-and-revoking-permissions) instead of `navigator.permissions`, with the intention of reserving the latter for permissions that _do_ exist in browser which we might also support isomorphically.

Since it's not ideal to have two separate `permissions` namespaces, we've been discussing just moving them all to `navigator.permissions` which would use a union of the w3c `PermissionName` and the one defined above.

My concerns are that:
1) This violates the spec of `navigator.permissions` in the way it is currently written. Could it be changed to allow any DOMString as a permission name instead of an enum? Instead of throwing for unsupported permission names, could it return `{ state: "unknown" }` or something? Ref #130, #136.
2) There could be name conflicts in the future between the web's and Deno's permission names. We can address this by prefixing our permission names with "deno-*", I guess. Thoughts on that?

---

Given all of that, is it more advisable for us to commit to having a separate `Deno.permissions` namespace forever, or moving to `navigator.permissions` despite the incompatibilities with the current spec? (What's the status of the suggestions linked in concern 1?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/212