You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2001/04/02 11:51:08 UTC
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
Re: AW: A plan for going beta with C2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@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
AW: A plan for going beta with C2
Posted by Carsten Ziegeler <cz...@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 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?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: A plan for going beta with C2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Matthew Langham <ml...@sundn.de>:
> 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?
+1
Please, go ahead and thanks!
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: A plan for going beta with C2
Posted by Davanum Srinivas <di...@yahoo.com>.
+1 - Go for it!!!!
Thanks,
dims
--- Matthew Langham <ml...@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
AW: A plan for going beta with C2
Posted by Matthew Langham <ml...@sundn.de>.
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
Re: A plan for going beta with C2
Posted by Peter Donald <do...@apache.org>.
At 11:51 2/4/01 +0200, Giacomo Pati wrote:
> * the avalon api goes beta as well (Peter can you update us
> about the plans for Avalon?)
No plans at the moment - will put out a proposal/vote to stabilize relevent
portions tomorrow and hopefully avalon will be ready in time.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A plan for going beta with C2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Davanum Srinivas <di...@yahoo.com>:
> Giacomo,
>
> The SAXConnector stuff from Paul was for Content Aggregation (See
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98363497918487&w=2) for
> more info.
After thinking about it I came to the conclusion that this way it is difficult
or impossible to achieve complete caching. A sitemap component *must* be able to
determine its cachability *prior* to the start of the pipeline because during
production it is not possible to determine that. Stefanos proposal has shown
that when a component depends on its input to determine cachability they cannot
be cached. Thus those SAXConnectors highly depend on their input to determine if
they need to request a sub-pipeline and thus the "main" pipeline those
SAXConnectors are in is not cachable at all (but maybe the sub-pipeline those
SAXConnectors requests).
Do you think my conclusions are correct?
Giacomo
>
> Thanks,
> dims
>
> --- Giacomo Pati <gi...@apache.org> 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?
> >
> > Giacomo
> >
> > ---------------------------------------------------------------------
> > 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!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>
> ---------------------------------------------------------------------
> 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
Re: A plan for going beta with C2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Davanum Srinivas <di...@yahoo.com>:
> Giacomo,
>
> The SAXConnector stuff from Paul was for Content Aggregation (See
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98363497918487&w=2) for
> more info.
Oh, I see. This is content aggregation based on xinclude, I think. Paul, please
enlight us about the status of this.
Thanks,
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A plan for going beta with C2
Posted by Davanum Srinivas <di...@yahoo.com>.
Giacomo,
The SAXConnector stuff from Paul was for Content Aggregation (See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98363497918487&w=2) for more info.
Thanks,
dims
--- Giacomo Pati <gi...@apache.org> 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?
>
> Giacomo
>
> ---------------------------------------------------------------------
> 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!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org