cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Caching system idea (was: status on c2?)
Date Wed, 17 Jan 2001 19:29:12 GMT
Sergio Carvalho wrote:
> On Wed, 17 Jan 2001 17:12:14 +0100
> Giacomo Pati <> wrote:
> > Sergio Carvalho wrote:
> > > Why isn't caching implemented as just one another element in the pipeline?
> > > Much like HTTP proxies get in the request path implmenting caching.
> >
> > You better use a proxy for this between your C2 and the clients (BTW I've
> > tested this and it really rocks that way).
> Ok, but then the proxy caches only the final result, not the components. Imagine a classic
page with a header, menubar, footbar and with the 'content' composed of news. A new story
in the content would invalidate all components and cause the whole page to be rebuilt, although
the header, menubar and footbar are the same and could have been cached (I'm sure you already
know this).

Yup. For what I use the proxy is 

a) stuff delivered from the ResourceReader which is non-XML data like
images or finally composed html documents (because they have to be
delivered under the same URI context C2 is responsible for). 

b) stuff produced from the SVGSerializer (if they are not dynamically
produced or can have a life cycle greater that one request (ie. 10 min.
or one day)

> I'll use the xinclude processor as an example. xinclude includes XML documents in other
XML documents. Besides doing this, unfortunately it also implements a caching algorithm. The
xinclude designer (thanks, man :-) opted for the standard HTTP caching algorithm, based on
the 'Valid Until' header. I say this is wrong. Not the algorithm, but the fact that the processor
contains the caching logic.

Yes, if C2 had a "intelligent" caching algorithm like if mentioned below
it doesn't need to have it's own one.

> This solution works for me, for the time being. What I don't like is the fact that I'm
tied to one caching mechanism. The guy who designed the xinclude processor didn't have enough
info on the included content to decide on the caching mechanism, and opted for the standard
http caching algorithm. My gripe is that he shouldn't need to choose the caching method. He
should design a simple processor that includes XML in XML, and be done.
> Then, when integrated on the document pipeline, I (the web system designer) who has the
necessary information, could place a StandardHTTPCache between xinclude and the included document,
thus producing the current behaviour. Or place a FooBarCache that implements a different algorithm.

Well, this is very tricky. How should a general C2 cache system be made
aware of the xinclude is including XML. What we need are interfaces
which tell C2 that there is something to cache. I think the
XincludeTransformer is a bad example to use for the caching system.
Maybe a content aggregation at the sitemap level suit this need better
(an can be better integrated into the cache system because it should
uses the standard way of a pipeline). I belive the pipeline is the main
point for caching (ie the 

What worries me is the fact that there are a huge number of parameter
which uniquely defines the data cached. XSP developers have to be aware
of it as well as component developers. The parameters identifying the
right data portion in the cache are the URI with all its parameters as
well as other stuff like coockies. 

> With this design, the only thing pipeline processors do is ask their inputs whether they've
changed. Some of their inputs are other processors and will do the same, other inputs are
cache processors, that know whether the input has changed, using some perverted logic someone
invented. When you design a processor, you never have to think about caching algorithms and
invalidation triggers. Every processor relies on CacheProcessors to do it. And these are chosen
at pipeline design time, when the information needed to choose/optimise caching is known.

What is a processor?

> It seems to me that smaller, simpler pipeline components lead to a better, more flexible,

Not really. It could lead to a huge cache store invalidating itself all
the time.


> I'm currently finishing a project that is entering testing phase in February, so I'm
unavailable until mid-february; but I'd like to lend a hand to C2 development by then, and
I don't mind implementing these ideas. Give me your thoughts.
> >
> > Caching is much mor that "another element in the pipeline". It might be one
> > component between every pipeline "element" to get at all cachable stages in
> > the production of a resource. Interfaces on the components should state if
> > the output of that component is cachable and an algorithm which determines
> > the point in a pipeline where caching should start or cached data should
> > replayed into the pipeline must be found.
> >
> > Giacomo
> --
> --
> Sergio Carvalho
> ---------------
> If at first you don't succeed, skydiving is not for you
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

View raw message