WSGI: the good and the bad
WSGI is the Python 'Web Server Gateway Interface', which is a standard interface between web servers and Python web applications. The idea is that you write your app as a WSGI app, then glue it to the web interfaces of your choice: CGI-BIN, SCGI, a standalone testing web server, whatever. The WSGI stuff encourages a stacking model, where modular middleware can be transparently inserted above applications to handle various more or less generic things.
(Ian Bicking gives examples of a bunch of WSGI middleware here.)
A while back I converted DWiki into a WSGI application, and in the process I built up some opinions about the good and the bad of of WSGI.
The good: the ideas. A generic execution environment for web apps is very nice, and the 'stack of simple pieces' approach to apps is a powerful and addictive idea. Plus, WSGI gateways are relatively easy to write, and for apps the interface is pretty simple.
The bad: the complex implementation, which imposes what I call the 'WSGI tax'.
The WSGI tax exists because WSGI had to fit into several existing web server environments, all different, in order to get people to adopt it. To cope with all of them, the full WSGI protocol has a bunch of complex requirements, and general WSGI servers (including all middleware, since it acts as a server for the layer below it) has to support all of them. Not only does this require a pile of cookie-cutter code in each middleware component, but the requirements significantly complicate what you can do when.
I really like the idea of stackable little bits, and I've been very happy with using it heavily in the post-conversion DWiki. But the WSGI tax is too much for me, so DWiki uses a much simpler internal protocol for its stackable layers and appears as monolithic WSGI app to the outside world.
(For scale, a typical DWiki stackable layer is ten to twenty lines of
Python. The smallest is three lines, not counting the
def; another is