[hunchentoot-devel] mod_lisp anyone?

[Ralf Mattes]

On Thu, 2008-04-10 at 08:59 -0400, Robert Koberg wrote:
> 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

In case you responded to my message: did I ever mention mod-xslt2? We
use our own xslt transforming module using Daniel's excellent libxslt
(unfortunately the module is named mod_xslt, but it's actually much
older than the well known modules :)
When I hacked the first version it was meant as a joke to make fun of
the java software used back then. I can't really comment on mod-xslt2
since I only use it on a rather seldom exposed area of the website but I
don't think it's especially slow. My only critique would be that it
suffers from a severe "second implementation syndrome" - there _seems_
to be quite a lot of premature (?) optimization and feeping keaturism
IMHO. Our little module doesn't even bother to cache the compiled
stylesheet - every request reads, parses and compiles the needed
stylesheets (and boy do they overuse includes and imports :-) and the
transforms the content. So far we seldom had performance problems, even
so the site runs on stock server hardware. 
   
> 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/>

Where's my babelfish? 


> 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).

Yeah. Only XSLT 1. IMHO that's a feature, not a bug. XSLT 1 had a very
clear operational model (by accident, i fear, they seem to have
inherited it from the DSSSL past) that should be near and dear to us
Schemers^H^H Lispers - purely functional without assignment.
  
> 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.

Last time we tested that wasn't a convincing option since that required
the transfer of stylesheets (since the site uses a rather modular
stylesheet setup that resulted in a noticeable increase in server load).

 Cheers, RalfD
 

> best,
> -Rob
> 
> 
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel