- From: Alex Russell <notifications@github.com>
- Date: Tue, 19 Apr 2016 10:42:36 -0700
- To: w3c/permissions <permissions@noreply.github.com>
- Message-ID: <w3c/permissions/issues/83/212036922@github.com>
Hey @martinthomson, @jan-ivar: I'm not sure I actually understand the concerns being raised. Requesting a geolocation permission via `Permission.request()` will have exactly the same side-effect (UI being shown) as `navigator.geolocation.getCurrentPosition()` or `navigator.geolocation.watchPosition()` and conceptually can also do acquisition (use) by providing the resource in the per-API subclass of `PermissionStatus`. The separation of "acquisition" in the case of geolocation is down to legacy API design. In a future where all API designers can rely on browsers to have implemented `Permission.request()`, it will be possible for them to avoid doubling up API or separating these. In the interim period where Mozilla (and others) have failed to implement the full API, it's harder to give advice to API authors that they should not also provide their own API. That said, the TAG is working toward that future by making sure that all APIs which can have a permission are at least designed with the Permissions API in mind. Next, as @jyasskin points out, we don't have data to confirm your fear despite have quite a lot of use of similar APIs in Android M. The risk of showing UI is itself the primary consequence that developers seek to avoid (and why the reflection side of the Permission API is so powerful) and _that_ is what creates incentive to put use in-context. Lastly, as a matter of platform consistency, you should think of the Permission API similarly to the Promises API: it's a new primitive that we need to work to expand integration and use of and is a project we're actively working on as new APIs come across the transom. Pointing to the fact tha some legacy APIs already have their own (inconsistent, frequently broken, badly designed) `request*` methods doesn't say anything about how we should improve the situation. With that perspective, I hope you'll come to view the Permissions API as the solution and not the problem. [Having personally done the (relatively brutal) TAG review](https://github.com/w3ctag/spec-reviews/commits/master/2015/03) of the API, I certainly came to that conclusion. Regards --- 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/83#issuecomment-212036922
Received on Tuesday, 19 April 2016 17:43:49 UTC