cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Re: idle thoughts in caching in c2
Date Tue, 23 Jan 2001 15:10:27 GMT
On Tue, 23 Jan 2001 13:22:18 +0000
Stuart Roebuck <stuart.roebuck@adolos.co.uk> wrote:

> With regard to placing caching components between processors and consumers.  What does
this mean in practice?  As far as I see it, we have generators, translators and serializers.
 Aggregators are a special case of generator.  If we could assume (or even stipulate) that
the behaviour of translators and serializers should be entirely determined by their input,
then it would make sense that caching of data always happens at the end of a match pipeline
and that caching algorithms used automatically are determined by the type of generator and
match.  The API of a generator could be extended to allow for an optional hash generation
method which would be required to generate a hashcode based upon any given generator input.
 Simple generators that know that their output is purely dependent upon an input file could
generate the hash code based on the file name and date.  More complex generators might also
base it on inputs like time.  By default all generators would generate hashc!
odes based upon their actual output data.

What you are saying is that caching should only be done at the end of the pipeline. Then it
is really, really important to enforce that translators' output is based solely on their input.
I am not at all familiar with C2, but if stuff like the XSP processors gets used as a translator,
it is possible to gather data from sources other than the input specified in the sitemap;
making it impossible to check cache validity using solely the producers. 

I am confortable with that solution, when there's no content aggregation. In fact, this solution
is very elegant. Each generator must be able to tell whether it has changed, and when true,
the cache invalidates its contents. I still want to be able to override this method when I
need to, but I guess it can be done writing a translator implementing my behaviour. 

When there is content aggregation, each content branch must have its own cache. From your
description, resources may be the solution. If resources behave as generators, then this model
just gets a recursive behaviour and works like a charm. 

--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com

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

Mime
View raw message