cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: AW: A plan for going beta with C2
Date Mon, 02 Apr 2001 11:37:02 GMT
Quoting Carsten Ziegeler <cziegeler@sundn.de>:

> > 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'd like to suggest to create a new classpath on reloading only (not on sitemap 
modification) because it is usually the concern of the deployer to install new 
jars (not the sitemap maintainers).

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

+1

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

+1 because these changes are rather trivial IMO and can easily flow into it.

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message