This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSL processor authors - how about this approach?
- To: xsl-list at mulberrytech dot com
- Subject: Re: XSL processor authors - how about this approach?
- From: Eric van der Vlist <vdv at dyomedea dot com>
- Date: Mon, 13 Mar 2000 15:53:06 +0100
- Organization: Dyomedea
- References: <8BD71A154EA6D211873E00105A125CDF19EA47@TSSMX1>
- Reply-To: xsl-list at mulberrytech dot com
Hi,
Dylan Walsh wrote:
>
> >Date: Wed, 08 Mar 2000 12:41:47 +0100
> >From: Eric van der Vlist <vdv@dyomedea.com>
> >Subject: Re: NewBie Question - Dynamic XSL
>
> <snip>
>
> >In this architecture, the operation which is taking most of the cycles
> >is the parsing of the XSLT sheet (which can take several seconds) and is
> >most of the time cached.
>
> Has anyone considered this kind of solution for server-side XSL? :
> Take the stylesheet, parse it and generate a custom servlet to perform this
> transformation. Then everytime XML needs to be transformed, this servlet
> could be run. This approach is a bit like JSP. You can do thorough
> optimisation when creating the servlet. It may even be possible to identify
> sheets that don't need random access, and switch to serial mode for those,
> saving memory.
> I would think that having custom generated Java code to move the data around
> would be faster than trying to figure out the stylesheet at run time. Great
> potential here for a performance boost?
You're right.
I think I have seen similar approaches mentioned by Resin
(http://www.caucho.com/products/resin/index.html) and also in the Cocoon
mailing list (but I don't think Cocoon is implementing this yet).
Hope this helps.
Eric
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea
http://xmlfr.org http://ducotede.com http://dyomedea.com
------------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list