[hunchentoot-devel] mod_lisp anyone?

[Hans Hübner]

Thanks, all!   I think removing mod_lisp support is the right thing to
do for the moment, as there is enough other work.

-Hans

2008/4/10, Robert Koberg <rob at koberg.com>:
>
>  On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
>  > 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 ...
>
>
> mod_xslt2 seems pretty limited. From:
>
>  http://www.mod-xslt2.com/doc/manual.xml?sect=5
>
>  5.1.9  Increasing performance
>  <snip/>
>
>  Since mod-xslt2 is part of apache itself, a pipe is impossible to use,
>  unless we fork apache one more time, slowing things down.
>
>  The simplest approach has thus been used: creating a temporary file, let
>  other modules write the replies in there, and then parse the temporary
>  file. However, by using temporary files, we hit I/O performance issues.
>  <snip/>
>
>  plus, it is only XSL 1.0. There was someone working on an XSL processor
>  in lisp, but I don't think it is ready yet (forgot the name).
>
>  Java is currently the best environment if you have to deal with XSL
>  transformations server side. If you are using XSL 1.0 only, you could
>  just do the transformation on the client -- pretty much all browser now
>  support XSL 1.0.
>
>  best,
>  -Rob
>
>
>
>
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>