Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3A65B901.4030308@apache.org>
Date: Wed, 17 Jan 2001 10:23:45 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 0.7) Gecko/20010109
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: AW: Status of XMLCompiler - Please vote...
References: <01011110482300.00465@sheepy>
 <NEBBLPMLKKCJBKEOKNFHKELNDJAA.cziegeler@sundn.de>
 <20010117121742.N703@hydrogen.internal.luminas.co.uk>
 <3A65A5BB.C96B7966@anyware-tech.com>
 <20010117145155.A20502@hydrogen.internal.luminas.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul Russell wrote:

> * Sylvain Wallez (sylvain.wallez@anyware-tech.com) wrote :
> 
> 
>> BTW, if Ozone and DBPrism use XMLC, it could be better as part of Xerces
> 
>> than Cocoon, even if it has no direct dependencies on Xerces.
> 
> 
> 
> I reeeeally *really* don't like this. If it's not part of Xerces, it
> 
> shouldn't be there, and if it's not part of cocoon, it shouldn't be
> 
> there (at least not directly). Should it be a separate project in its
> 
> own right? Perhaps there should be a project to develop a suite of these
> 
> XML 'transcoders' (someone think of a better name for me? English never
> 
> was my strong point. yes, I'm english ;)


The Cocoon project calls them Generators.  Let's keep the same name.

Here is my spin on it: if the events will be called quicker by actually
compiling a class and calling the methods like XSP, then we should
determine by how much very easily.

Take two files of roughly 100k each.  The _only_ difference between them
should be that one is treated as an XSP, and the other as an XML page.
There should be no tranlators involved, and serialized as XML.

NOTE: the XSP page may require the use of the <xsp:page> tags as the
root.

For an example of a small page like this, look at
webapp/docs/samples/forms/add-department.xsp

Access them each 11 times (throwing away the first time).  Average the
last ten times (the compile is the first access).  If the average of
the compiled sheet is significantly faster than the average of the
uncompiled sheet, then it might be worth investigating this further.
Otherwise, lets cut our losses because the RCT (Really Cool Technology)
won't buy us enough of a performance edge.

The next test is to create a Generator that reads the file into a string,
and parses the string over and over--using the same test and test file.
Then you will see what caching at the XML level will and will not do
for you.

My take is that for static pages, we cache the final result.  For
dynamic pages we cache from the most static portion (Cocoon 2 really
already does this for XSP--because the classloader caches the
serverpages Generators).