[hunchentoot-devel] mod_lisp anyone?

Edi Weitz edi at agharta.de
Thu Apr 10 12:29:44 UTC 2008


On Thu, 10 Apr 2008 14:13:24 +0200, Ralf Mattes <rm at 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?



More information about the Tbnl-devel mailing list