cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [vote] move tree-processor in the main trunk
Date Thu, 07 Feb 2002 15:58:29 GMT
Stefano Mazzocchi wrote:

>sitemap code generation is getting slower every day and is likely to
>become worse as we add more bugfixes and error generation.
>Clearly, developping on cocoon with 20 seconds delays between changes is
>a nightmare and would scare people away instantly.
>Now that we have a functional interpreted sitemap engine, I suggest we
>move this on the main trunk and keep improving on it from there.

>Also, I would like to propose a name change: TreeProcessor isn't exactly
>self-explanatory as a 'sitemap interpreter'.
Just to make things clear : sitemap is only one of the possible uses of 
the TreeProcessor : it's a generic framework for implementing pipeline 
assembly languages (hence "Processor") with an evaluation tree (hence 

The supported languages are defined in treeprocessor.xconf or 
cocoon.xconf, and the interpreted sitemap is "only" a particular 
pipeline assembly language implemented using this framework, but we 
could implement others like Berin's proposal or Daniela Gehle's flowmap 
(go back to october 2001 in the archives to find them).

Having this clear in mind, there's no problem to speak of "interpreted 

>Moreover, I'd love to be able to decide what to use (interpreted or
>compiled) from cocoon.xconf.... or, in case the treeprocessor ends up
>faster all the time, simply blast the compiled version and get rid of
>that stupid javac!
The Processor used by Cocoon is a regular component : just change the 
class of the <sitemap> in cocoon.xconf and you're done !

And if we decide to blast the compiled version, we just have to change 
the default class in cocoon.roles. But let's both live together until 
we're sure the interpreted version is bug-free.

>What do you think?
Sounds good :)

However, I'd like to propose some package renaming to better organize 
things (inspired by some off-list discussion with Vadim) :
- org.apache.cocoon.components.treeprocessor : the TreeProcessor framework
- org.apache.cocoon.sitemap : classes common to both implementations
- : classes specific to the compiled version
- org.apache.cocoon.sitemap.tree : classes specific to the tree-based 

Vadim proposed to insert "processor" before sitemap (i.e. 
"org.apache.cocoon.processor.sitemap") to outline the fact that sitemap 
is only one implementations of Processor among others, but I don't think 
such a depth is necessary unless we think to have more than a dozen 
different languages ;)

And also, we should start discussing the integration of schecoon and 
interpreted sitemap, and more generally about Processor implementations 
that coexist in the system. I was thinking about some ProcessorManager 
or ProcessorSelector that any xxmap ('xx' = 'flow', 'site' or something 
else) could query to get others xxmaps (e.g. a sitemap calling a 
flowmap). I don't have clear thoughts about that, but it seems to me it 
should be able to discriminate Processor instances by the language 
(xxmap), the source file that defines it and the mount path (since a 
subsitemap behaviour depends on its parents).

Thoughts ?


Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message