cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Re: Caching system idea (was: status on c2?)
Date Wed, 17 Jan 2001 17:13:06 GMT
On Wed, 17 Jan 2001 17:12:14 +0100
Giacomo Pati <giacomo@apache.org> 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). 

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.

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.


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.


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

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
---------------
scarvalho@criticalsoftware.com

If at first you don't succeed, skydiving is not for you

Mime
View raw message