- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Apr 2016 16:22:47 +0000
- To: public-media-capture-logs@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-main: == New permission definitions are wrong. == Sorry for not becoming aware of this sooner, but it's deeply concerning to me that we seem to recently have tied ourselves to the definitions in the document describing the web-facing Permissions API, which seems primarily to be about how web pages can view the state of *persistent permissions* (`'prompt'`/`'granted'`/`'denied'`). That whole spec is built on that triumvirate of states, making it inherently suited for requesting the state of persistent permissions only. They're necessarily persistent, because permission absent context needs to persist for some length of time, as it's not tied to anything else, like a successfully requested object. This seems like an impedance mismatch for our needs. Our spec needs definitions for *request for access*, which we should be careful not to confuse with *request for (persistent) permission*. This is perhaps most obvious with the state [`'prompt'`](https://www.w3.org/TR/permissions/#idl-def-PermissionState-prompt), which means the user gets a prompt *when they later request access*. Clearly *request for access* must be separate from *request for permission* or there's a circular definition, yet their *request for permission* algorithm just returns the aforementioned triumvirate (I pick apart that algorithm in https://github.com/w3c/permissions/issues/85#issuecomment-213434671). Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/350 using your GitHub account
Received on Monday, 25 April 2016 16:22:49 UTC