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))) One can see how a middleware function could set things up for the user-defined handler, could decide whether or not to call the user's handler and could override whatever that handler returns. A convenience macro def-middleware might make it possible to write the null-effect function like this: (def-middleware null-effect (request) (call-next-middleware)) And the user might be able to create a dispatcher thus: (create-regex-dispatcher "/foo/bar?baz" (null-effect #'my-handler)) Obviously middleware could be chained: (create-regex-dispatcher "/foo/bar?baz" (authentication (caching #'my-handler))) Question: does this seem like a reasonable way to handle middleware, particularly authentication/authorisation mechanisms? I'm fairly new to Lisp, but it _seems_ like it's a fairly Lispy way to go about things. Thoughts? -- Robert Uhl <http://public.xdi.org/=ruhl> England really needs France around to provide comic relief. --Matt McLeod in comp.sys.mac.games.strategic