cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: AW: A plan for going beta with C2
Date Mon, 02 Apr 2001 10:35:35 GMT
+1 - Go for it!!!! 

Thanks,
dims

--- Matthew Langham <mlangham@sundn.de> wrote:
> Hi,
> 
> >>
> 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).
> <<
> 
> As we have already said, we would start work on the caching side asap.
> Unless of course someone else would like to do the caching.
> 
> So...shall we?
> 
> Matthew & Carsten
> 
> 
> --
> Open Source Group               sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel: +49-5251-1581-30   [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
> 
> 
> -----Ursprungliche Nachricht-----
> Von: Giacomo Pati [mailto:giacomo@apache.org]
> Gesendet: Montag, 2. April 2001 11:51
> An: cocoon-dev@xml.apache.org
> Betreff: A plan for going beta with C2
> 
> 
> 
> 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?
> 
> Giacomo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

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


Mime
View raw message