On Thu, 2008-04-10 at 13:54 +0200, Hans Hübner wrote:
Hi Ralf,
can you come up with concrete examples of what could be configured with Hunchentoot and mod_lisp that would not be possible in a mod_proxy setup?
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 am relatively easy to convince that keeping mod_lisp support is a good idea, but I'd still want to know what exactly these advantages are.
With respect to other comments:
I do like the idea of using a streams based approach to mod_lisp and raw http support, as Arjan has suggested. I am not sure if I will make this change soon, though, and if I could start by removing mod_lisp support, it would make life easier for me as well.
+1 from me.
It would be helpful if Robert and/or Andrea could write down how session support needs to be enhanced.
Thanks, Hans
Thanks, Hans
Cheers, RalfD
and thank's for working on hunch