cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: [C3] Caching
Date Tue, 23 Dec 2008 09:56:24 GMT
Carsten Ziegeler schrieb:
> Reinhard Pötz wrote:
>> I would only make the caching file generator available to the sitemap.
>> If you put it into a caching pipeline, its caching interfaces will be
>> regarded, if it is used in a noncaching pipeline, the
>> CachingPipelineComponent interface will be disregarded.
> Hmm, yes, sounds much simpler :)
>> I'm not sure if it is a good idea to introduce aspect orientation at
>> this level which adds a further level of complexity.
>> I also fear that this will not be a solution that works for every
>> scenario and if it's only one component that can't be cached
>> transparently by AO mechanisms we get a problem where to put it because
>> we wouldn't want to introduce a dependency on the caching module.
> Hmm, I don't meant real aop - I haven't looked into the caching pipeline
Hmmmm, if not *real* AOP what then?
> impl, but I guess it checks each component if it implements the caching
> pipeline component interface. If the component does not implement it,
> the caching pipeline could try this default behaviour.
> Without thinking this through, I see two downsides: the cache key might
> contain stuff which is not required (this should be neglectable). The
> pipeline ends up to be always cacheable, regardless if the components
> itself support caching - this might be not the desired effect - I don't
> know :)
I'm not sure I would like a system where I cannot "disable" a feature, 
even if I want it.
There might (iow. will)  be situations where  a result must be 
regenerated, even if all input parameters remained the same (just 
imagine using a CMS, Database, Index, etc. as input).
If the system keeps using the old result because the query for the DB 
did not change, you're screwed...

On the other hand, I guess it would be rather difficult to provide a 
caching mechanism with an optional module that can work with virtually 
any component that might exist.
Of course we can extract all the caching that exists now into a separate 
module but everything that needs caching would have to depend on it.

>> If we want to clean up the cocoon-pipeline module, it's probably a
>> better idea to create a 'cocoon-sax' module and we move all SAX related
>> classes there. Then 'cocoon-pipeline' contains the core interfaces and
>> the pipeline implementations (incl. caching).
> I think we should do both :)
I think we should definitely separate the SAX components from the 
pipeline. Especially with StAX coming.
I'm sure this will make the pipeline-module quite small and nice...

Regarding the whole topic
In your first mail you wrote: "there are too many interfaces which might 
confuse users"
Mind explaining what you mean?

IMO a user won't have to deal with many of the interfaces at all - even 
if (s)he uses the pipeline API directly (iow programmatically), not to 
mention when using the sitemap.
Someone who actually deals with the Cocoon code shouldn't have too much 
trouble - especially when comparing it to Cocoon 2.x.

IIRC this isn't the first time that someone said "Cocoon 3 is already 
too complicated because of too many/much ..." (e.g. interfaces, modules, 
complexity etc).
I mean Cocoon 2.x is at least 5 times as much as Cocoon 3 - no matter 
what kind of metric you use (I'm just guessing here, didn't actually 
So how come a considerably smaller/simpler approach is suddenly too 
complicated or too confusing?
> Carsten

View raw message