** new handler model [ I think everything in here has now been wrapped into one or more of the real doc files ] a handler is an object with various methods defining the actions for different stages a dispatching handler calls authent, authz, then dispatches on the sub-handler, then logs We put the request method in as a specialisable argument - it's not unusual to do different things for GET and POST at the same url. There is no error handler any more: a dispatching handler should do a handler-case and etc if it wants to (How this meshes with the existing system: export-handler installs a "legacy-handler" at the appropriate url prefix - unless there's one there already) Stages may signal RESPONSE-SENT to short-ciruit subsequent stages. This can also be used by REQUEST-SEND-HEADERS to skip sending the body. and so forth. Note that it's a signal not an error, so in a legacy handler system if its not caught it'll be ignored we also need some way to deal with request-base-url and/or rest-of-url. I propose that the request get new slots ((urlstring :initform nil) (handled-by )) handled-by is a list of lists we should detect when the handler is a function, and just call it. We don't always need the full object stuff if it's just doing something simple like a redirect *root-handler* is always called first. as we go through each new handler we cons the appropriate list of handler-instance and position within the urlstring that has been examined.