Re: [w3c/permissions] Drop .request() (#83)

@jyasskin Thanks for the [polyfill](https://github.com/chromium/permissions.request/blob/master/permissions.request.ts#L268). Hopefully it clarifies for everyone that `.request()` as proposed would be an API for requesting ***functionality***, not for requesting *permission* for said functionality.

Historically, specs draft APIs around functionality, not externalities of functionality such as whether something is allowed or not. We have web developers ask for the camera, not ask for elevation of camera permissions in order to get a camera stream as an aside.

This PR violates that, and is stealing the API surface of any spec that has a powerful feature. Hopefully, there won't be a future API corralled around some other externality, like the configuration or storage needs of a feature, or we'll have three or four ways to do the same thing.

I understand the impulse that when we can query something, we want to set and clear those things as well. However, setting and clearing of permissions is expressly implicit in using functionality on the web, by design, for the good reasons outlined in [roc's blog](http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html) (to prevent the permission bundle problem).

About bundling, @alvestrand said:
> ... the "request by using" paradigm, while applicable to a lot of cases, has the nasty side effect that applications whose logic really lend themselves to request() will try to acquire sources they don't need in order to make sure they have already done the dialogs if they need them later.

Not all browsers auto-persist permissions, so the payout of such arm-twisting is more rewarding in Chrome. Roc calls those "**Greedy Applications**". He says: *"One wrinkle is that lazy app developers can turn the "permissions in context" model back into the "bundled permissions" model by activating APIs up-front and refusing to let the application proceed until all requests are granted. My hope is that if most apps don't behave that way, users will develop higher expectations and be distrustful of lazy apps."*

This has mostly held (he said that in 2011). In any case, the way around that problem is not to piggyback said functionality onto the setting of permissions. That's awkwardly backwards, an attempt at a cross-domain (lateral) API. [Even WebIDL is screaming](https://github.com/w3c/permissions/issues/42#issuecomment-242634068).

Asking web developers to pivot to "permissions" as a concept to access functionality seems to encourage bundling, if not in function then in form. It will make them "lazy". 

Now, looking at the two lone [pros](https://github.com/w3c/permissions/issues/83#issuecomment-215247344) that have been mentioned for this PR:

> 1. Provides a new spelling for several old APIs where we can get their interfaces right.
> 2. Provides a uniform spelling for requesting a permission so developers don't have to learn the intricacies of each capability's request function. (This is tempered by each capability getting to refine its PermissionDescriptor, probably in non-uniform ways.)

These both seem aimed at lazy developers who don't want "to learn". That's a con in my book.

For instance, did you know that to immediately relinquish a hardware device you've obtained with `getUserMedia`, you must call `stream.getTracks().forEach(track => track.stop())` ?

We *want* people to learn the intricacies of each capability's request function. One is not like the other.

-- 
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-242649154