-
Notifications
You must be signed in to change notification settings - Fork 0
Scribe scope revised
Scribe has been out for a few years now, becoming one of the (if not the) most important OAuth libraries out there. A lot of patches and issues have been submitted by tons of people, all around the world. That is awesome and I thank you all for your contributions. We all did this.
At first, scribes job was to provide a super easy, extensible and bug-free way of OAuth-signing requests. Version 1.0 was great and after polishing some rough edges the lib became rock solid. Of all the bugs reported in the last 2 years, none has been significant or critical. The lib has been tested on different platforms (android) and consumed by java, groovy and scala code. It works.
That should be it right? Success. Well not really. While Scribe code is concise and clear, the project is a mess. There are hundreds of issues open and pull requests to be merged. Every single day I get support emails. Every single day I check stack overflow for new questions tagged with "scribe".
It's not a full time job, but it's close to half that at least. And obviously I don't have the time.
I have to choose what Scribe is going to be, and most important, what is never going to. So here's the bullet list:
OAuth 2.0 support is not going to get any more attention and may eventually be deprecated and dropped.
Two reasons:
-
OAuth 2.0 is a lot more fragmented than 1.0, the spec is too broad and not strict enough so every provider out there is doing whatever the fuck they want. I'm not willing to spend my time chasing them.
-
It's easy. Really. OAuth 2.0 doesn't involve half the shit you need to do in an old 1.0 signature. The moving parts are tiny and any competent developer can hack a snippet that works with a 2.0 provider in a few hours (if you can't then using a library will only postpone a more dangerous problem for you and your employer).
This is by far the most common pull request type. At first I wanted Scribe to work with any provider out of the box. It sounds cool and it's great for beginners. I also created working examples for each of these so people could have a great runnable tutorial. What's wrong with this?
-
I was underestimating developers. Coding your
Apiclass is dead simple, you don't need one out-of-the-box for every provider you need to use. You can check one or two examples and get up to speed in no time. -
The code grows with every Api + example PR. It takes longer to compile. Line count and jar size increases for no reason (there's no opting out of all the
Apiclasses you get for "free"). -
Most of the time
NewShinyApineeds tweaks and if statements in the "core" so that it can work becauseNewShinyprovider thought "fuck the spec I'm returning whatever".
If your PR breaks (or adds, or deprecates, or whatever) the public api, 99.99% of the time it will get rejected. So please ask before spending hours of work in it. I do want to merge everything and keep everyone happy. But Scribe can't be all things. It can't even be many things. It has to be only one simple thing and that is a library that makes OAuth request singing dead simple.
I do want to merge everything and keep everyone happy. But Scribe can't be all things. It can't even be many things. It has to be only one simple thing and that is a library that makes OAuth request signing dead simple.
Sorry for closing your ticket or not merging your patch. And thank you.