WSGI is a barbones standard which allows Python web servers to talk to Python web applications. That's really all it's meant to do. For instance, using WSGI you should be able to relatively easily hook up, say, Twisted's HTTP server to a Zope application. Or hook up an Apache with mod_python to a Webware application without using mod_webkit. And so on.

If that's all it did, I have to confess I wouldn't be all that interested in it. I mean, it's useful, but it's a "write-once" sort of thing... you make your app WSGI-compatible, and it helps other folks. But it also has this tantalizing, intriguing concept of "middleware". A WSGI component can be a "server" or an "application", or it can simply be both. If it is both, it becomes middleware, aka a "gateway". When a WSGI server talk to an application, the conversation can be mediated by this middleware. Any number of middleware components can be strung together to form a pipeline. The pipeline "ends" at the actual application. Mike Orr provides a code examples of what WSGI middleware might do in this article .

Ian Bicking's Paste is a web app framework which takes advantage of WSGI middleware to provide services. Paste implements services like URL parsing, sessioning, authentication, and other things that are typically managed by individual web frameworks as WSGI middleware components. This makes a lot of sense to me. It potentially means that web framework authors can get out of the business of needing to maintain their own implementations of these types of services and instead get into the business of reusing "best of breed" service implementations out of middleware "Legos".

However, a thread on Python's web-sig list indicates that there isn't broad consensus on whether this is an effective use of WSGI middleware. The primary argument against doing this is that creating a pipeline out of many middleware components may "pollute" the call stack and make these kinds of applications slower than they might otherwise need to be. Apparently, the intent of middleware is for completely self-contained transformations. In Phillip Eby's view, at least, WSGI middleware should be "oblivious", meaning that it shouldn't depend on services added by other middleware nor should it provide services that are depended upon by other middleware.

Phillip ponders that maybe instead of implementing servicelike things like authentication and sessions as middleware, that we allow WSGI applications to have a "context" upon which is hung some methods which would allow the end-point application (or middleware components themselves) to retrieve "services" instead.

But there isn't yet anything in the WSGI specification to allow for this. Adding it puts WSGI into the business of being a web framework, something that it explicitly tries not to be via language in the PEP. So there's understandably some impedance mismatch here, and it may never be worked out.

Personally, I'd like to see WSGI grow some extensions to allow for this sort of thing because I think it would help framework authors share code more readily. In the meantime, Paste is a pretty impressive demonstration that you can use WSGI middleware to achieve the same result, so perhaps it's not even necessary.