cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: A plan for going beta with C2
Date Mon, 02 Apr 2001 11:12:28 GMT
> Giacomo Pati wrote:
> Hi all
> Here is a plan for going beta with C2
> The disccussion so far has discovered that we want to go beta 
> around 1st of
> May
> if:
>   * we can implement content aggregation at the generator stage.
>   * we can implement at least a rudimentary caching (e.g. at the generator
>       stage only).
>   * the avalon api goes beta as well (Peter can you update us
>       about the plans for Avalon?)
> For content aggregation we need:
>   - refactoring the ResourcePipeline class into a pure xml part
> (XMLPipeline)
>     and a part that is able to serialize this xml part (BTW: IIRC this was
>     proposed by Ricardo a few weeks ago, to tell the truth :).
>     (I'm already doing this).
>   - enable a separate control path to get at those XMLPipeline evaluated
>     by the sitemap engine to allow an AggregatingGenerator to 
> collect those
>     XMLPipelines for aggregation.
>     (will do this as well because it is closely related to the factoring
>     above).
>   - write a AggregatingGenerator which, according to some kind of
>     "configuration", is able to collect XMLPipelines and assemble a final
>     stream of SAX events.
>     QUESTION: Does it make sense to restrict the access to the separate
>     control path mentioned above to this generator only? I know it can't
>     be restricted technically but I think it should not be proposed to use
>     the separate control path by any custom written component. But it can
> be
>     enforced by introducing interfaces (IoC) for that purpose.
> For caching we need:
>   - components to measure the "cache efficency" for individual sitemap
>     components as well as for XMLPipeline as a hole.
>   - a component to "tee" SAX events into a SAX Store.
>   - a component to replay SAX events from a SAX Store.
>   - define how a component reports cachability (e.g. the Cachable
> interface).
>   - define how cache keys should be generated (there were two proposals
> IIRC).
> I've found some components introduced by Paul Russel (SAXConnectors) which
> are
> already put between individual sitemap components (Generator, Transformer,
> ...)
> in the resource production pipeline today (ResourcePipeline). Paul can you
> enlight us what you had in mind with those connectors? I've guessed they
> were
> for caching but I could be wrong.
> Other topics:
> Cleanup the docs. I'd like to put the C2 site docs into the xml-site as an
> subdir of the cocoon directory (xml-site/targets/cocoon/cocoon2). For this
> I
> need to change the xdocs/site-docs.xml in the C1 repository to have a link
> into
> this subdir. Robin, is this ok for you? Do you have any conventions we
> still
> need to do concerning to update the Cocoon site?
> What else have I missed?
One main valuable feature for a beta would be the reconfiguration of the classpath,
this means if new jar files are put into the webinf\lib directory and a new
cocoon instance is created (either forced or by sitemap modifications) these
new jar files should be loaded with the classloader.
I would also suggest to load the jar files in an alphabetical order (or any other
deterministic order), because if you have any class collisions with two or more
jar files, it is important to know in which order they are loaded.

What do you think, are these required features for a beta?


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

View raw message