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

Yes, promises are great.  And I get that our primitive engineer brains love to seek out patterns and try to tame them.

Where promises serve to replace an existing feature in a superior way, `.request()` cannot ever serve as a replacement.  The API that does something still has to exist.

Many of the benefits you claim to gain from `.request()` are actually realized by defining `.query()`.  I'm not arguing against that, it's a good idea.  Indeed, I see much of those benefits being realized in terms of codifying what permissions an API might require.  Those have a clarifying effect on the APIs themselves for the reasons @jyasskin describes.  We're learning a lot about the assumptions we've made and we don't need `.request()` for that.

If unification is your goal here (and leaving aside for the moment that we're not really talking about unification), we have to establish that a unified API has marginal utility that outweighs the negatives.  You are right to ask what the actual negative impact of decoupling is.  I've already seen some indication that these negatives are present with notifications, where a decoupled request is all we currently have.  A large site conducted an experiment on what style of prompting for push notifications got the best conversion rate.  Asking at page load time turned out to be best for their metrics.

I know that there is a desire to do the same for `getUserMedia()`.  I believe that there are a sizeable number of web developers who find the whole consent experience very frustrating and who would rather have it out of the way.

Install Skype on Android and witness what it does to destroy the contextual permissions thing when you start it up.

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