cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Problems with content aggregation and redirects
Date Wed, 27 Jun 2001 09:26:27 GMT
> Giacomo Pati wrote:
>
> On Tue, 26 Jun 2001, Carsten Ziegeler wrote:
>
> > > Giacomo Pati wrote:
> > >
> > > On Mon, 25 Jun 2001, Carsten Ziegeler wrote:
> > >
> > > > > Giacomo Pati wrote:
> > > > >
> > > > > Quoting Carsten Ziegeler <cziegeler@sundn.de>:
> > > > > > > Giacomo Pati wrote:
> > > > > > >
> > > > > > > On Fri, 22 Jun 2001, Carsten Ziegeler wrote:
> > > > > > >
> > > > > > > > > Michael Hartle wrote:
> > > > > > > > >
> > > > > > > > > Carsten Ziegeler wrote:
> > > > > > > > >
> > > > > > > > > > The CA example doesn't work as the aggregated
part
> > > > > > > > > (moreover/moreover.xml)
> > > > > > > > > > has no EventPipeline (it's a redirect).
> > > > > > > > > >
> > > > > > > > > > I think we should fix this. The easiest
solution
> > > for this would
> > > > > > > > > be to make
> > > > > > > > > > the cocoon: url work and use them from inside
the
> > > > > > > > > ContentAggregator as well.
> > > > > > > > > >
> > > > > > > > > > What do you think?
> > > > > > > > >
> > > > > > > > > Will the cocoon: protocol then later be used
as the
> > > only way for
> > > > > > to
> > > > > > > > > specifiy the source of an aggregation
> > > > > > > > > element ? If it is not so, then there would be
> two ways how
> > > > > > > aggregations
> > > > > > > > > can be used (with or without the
> > > > > > > > > cocoon: protocol) and this counter-intuitive
> issue regarding
> > > > > > sitemap
> > > > > > > > > redirects that are not being resolved
> > > > > > > > > would remain.
> > > > > > > > >
> > > > > > > > Yes, I personally would suggest that it is required
> to use the
> > > > > > cocoon:
> > > > > > > > protocol. But I think we have to vote on this.
> > > > > > >
> > > > > > > The sitemap aggregation was made exactly for
> aggregating cocoon
> > > > > > > pipelines because it aggregates XMLProducers not byte
> > > streams. I think
> > > > > > > aggregating other stuff is better suited by the xinclude
> > > transformer.
> > > > > > >
> > > > > > Ok, the CA was made to aggregate pipelines, but what about
> > > aggregation
> > > > > > different "xml sources" which could either be pipelines but
also
> > > > > > completly
> > > > > > different urls.
> > > > > > When (not if!) we have the cocoon: url the CA can do both
> > > of the above
> > > > > > without any change. And the great advantage over the xinclude
> > > > > > transformer
> > > > > > is caching as CA is cacheable and the xinclude not.
> > > > >
> > > > > The cocoon: protocol should server a ContentHandler but all other
> > > > > protocols
> > > > > represent byte streams. If you have an idea how the CA can
> > > > > distinguish them then
> > > > > go for it. Also if the cocoon: protocol serves a ContentHndler
> > > > > the CA isn't
> > > > > cachable as well (only its parts are).
> > > > >
> > > > Yes, currently I see a narrow path to distinguish, but
> first I want to
> > > > implement something to see if I am right or not (this will take some
> > > > days).
> > > > I thought that when all parts are cacheable the CA is also
> cacheable.
> > > > Correct? And I hope to make the parts with cocoon: url also to be
> > > > cacheable (and this is currently this is currently only a very thin
> > > > line I am walking on, but we'll see).
> > >
> > > How can a URL of a cocoon: protocol states its cachability?
> > >
> > This is one of the tricky parts I am currently thinking of: The cocoon
> > URL object is a "wrapper" around the corresponding EventPipeline.
> > The only thing to do is the calculate a last modification date for
> > this EventPipeline. Perhaps this is not possible. We will see.
>
> And the CA must be able to query that to report it up to the cache
> manager, right?
>
Yes, after some testing and checking, I could tell that you are right.
The cocoon: urls are not cacheable right now. There are even some more
problems to solve.
I hope I have a working version by the end of this week and we
could start discussing all the problems.

Carsten

> Giacomo
>
> >
> > Carsten
> >
> > > Giacomo
> > >
> > > >
> > > > Carsten
> > > >
> > > > > Giacomo
> > > > >
> > > > > >
> > > > > > Carsten
> > > > > >
> > > > > > > Giacomo
> > > > > > >
> > > > > > > >
> > > > > > > > Carsten
> > > > > > > > > Michael
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message