httpy is now WSGI middleware

For the record, I didn't invent WSGI. Not only that, I invented something called httpy to compete with it. That's how bad my NIH syndrome is.

But it turns out that WSGI has *ahem* seen somewhat better uptake than httpy. So I've swallowed my pride and rewritten httpy as a small piece of middleware. It's gone from 9500 lines of code (including 6750 lifted from Zope) to a single module with 64 lines of code! Wow! Yes, like maple syrup, httpy has been boiled down to its essence.

Now, regarding WSGI, I had two complaints: the API is ugly, and I'd rather share libraries than middleware. Well, the former still applies, but WSGI is supposed to be ugly, and httpy is exactly the sort of thing that is supposed to hide the ugliness.

I was just plain wrong about middleware: it's great! The key is the shared environ mapping, which amounts to a commons for Python web programmers. Everyone's middleware throws stuff in the pot, and we're all free to pick and choose from it. This works for at least these reasons:

• It's dead simple: it's just a dictionary.
• It's non-intrusive: you can ignore whatever you don't want.
• It honors the CGI standard and tradition.
  

I'm still pretty green with this, and I have to admit I have this lurking fear of middleware conflicts akin to what you see with packaging systems. However, the worst case scenario now is that I end up only using a small set of trusted middleware. I still get all of the decoupling and deployment benefits of WSGI. And now with httpy, I can generally avoid the crufty response API too. Feed back to Chad Whitacre.