I was playing around with making a WSGI server, and I'm starting to think that some really neat stuff could be done with middleware. (The rest of this post might not make much sense if you haven't read that spec.)
For instance, I was thinking about setting up something for Medusa with WSGI. But though I think asynchronous code seems like a good server architecture, I'm not that interested in it for applications. But this iteration of the WSGI spec allows for async pretty well; you can tell you are in that situation when wsgi.multiprocess is false and wsgi.multithread is false, and the iterator output can produce the data fairly well.
I then realized that threading itself could be a piece of middleware -- you just have to do the proper buffering with input and output, and spawn the necessary threads. An intelligent application that realizes it can't run as an async process could install this middleware itself when necessary.
Even multiprocess could really be implemented as a piece of middleware, either running CGI scripts, or forking worker processes. It could get out of hand if every application in a multi-application system had its own middleware; but the extension mechanism could also allow you to lazily implement these models, providing callbacks to access existing thread or worker process pools.
Another useful piece of middleware would be something for error reporting; it would basically pass everything through, but wrap everything in try:except:. Then you could develop and plug a nice debugger into whatever architecture, and the basic server can do just the most minimal error logging (basically print a traceback to the error log).
Despite it's low-level simplicity, I think WSGI could be a very capable building block for Python web programming -- something we desperately need.
I like your thinking here; I've read the spec, and am excited by it, too.
I was thinking for example, that this would help to make Twisted (or Medusa) the HTTPD for Webkit. One side is async, the other side threads, and wscgi in the middle.
# Matt Feifarek
What I find fascinating: that's exactly what I implemented with the Toolserver Framework for Python - http://pyds.muensterland.org/wiki/toolserver.html - a Medusa with integrated threading for dynamic tools. You have medusa for the static content delivery and can hook into it, if you want. Or you build tools (just some Python classes) that are dynamically loaded on server start and will be handled by dynamically allocated worker threads (much in the same way as Apache manages it's processes). So one side async, the other side threads, only the middleware is TooFPy :-)
Posessive "its" has no apostrophe.