On 7/20/07, Robert Uhl eadmund42@gmail.com wrote:
From Python's WSGI I've gotten the idea of middleware--that is, stuff
which runs around user-defined code in some user-defined order. A null-effect middleware function might be defined like this:
(defun null-effect (request next) (when next (funcall next request)))
It seems strange to talk about the concept middleware when you have only 1 webframework which will support it. The whole point of WSGI is to make your application capable of using any of the available python webservers, and all such applications and servers being extended in the same way through middleware (code that runs between the server and the application).
So you can have Zope3 application with xslt styling middleware + interactive through the web traceback middleware + twisted server. And you can add as much middleware as you want, change the server, or change the framework used to create the application without having to change the code of the other parts. (this is done by defining the way server passes information to the application and making all the servers conform to that way)
While something like that would be useful to common-lisp as well (being able to have hunchentoot based application run on araneida) or using AllegroServe as a backend for a UCW application. IMHO the place for changes to the code is inside the hunchentoot, AllegroServe and other web frameworks, rather than in the hunchentoot dispatcher.
And if it is only to allow some standartized "plugins" for hunchentoot that can be added to your working application in some easy way, then comparison with WSGI is a bit out of place.
Ignas Mikalajunas