On Thu, 10 Apr 2008 14:13:24 +0200, Ralf Mattes rm@seid-online.de wrote:
As I wrote in my last mail, I'm not currently using it. I kept mod_lisp as an option in case I need tighter Apache integration. I'm currently a little, erm, tight on time so I can't come up with elaborate examples now. One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
It might be possible to do this with mod_proxy as well, but I think it would be cneptually cleaner to view the Lisp process just as yet another content provider module.
I haven't worked with Apache 2.x filters yet, so I can't comment on this example. (But I think you're right and it's a reasonable example.) Filters were about the only thing that came to mind when I tried to come up with a reason to use mod_lisp because the standard (1.x) way of writing and combining modules as described in the nice eagle book doesn't really fit with how mod_lisp works.
So, yes, your case might be a good reason to use mod_lisp. Whether it is a good reason to have mod_lisp support in Hunchentoot I'm not so sure. Speaking of being conceptually clean, Hunchentoot has evolved over the years and now is (or aims to be) a fully-fledged stand-alone Lisp web server. 90% of its code base is probably totally useless if you're just trying to write a content provider module to hook into Apache. Wouldn't it make more sense to use something like cl-modlisp for this?