cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [C3] Caching
Date Tue, 23 Dec 2008 08:22:40 GMT
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> Carsten Ziegeler wrote:
>>> Hi,
>>> I just started with looking closer at the pipeline stuff we have for c3
>>> atm. My first impression was that there are too many interfaces which
>>> might confuse users :) As we step away from just a sax based pipeline, I
>>> fear we really might need all these interfaces :(
>> I've already prepared a proposal in my drafts folder that if accepted
>> will introduce another interface ;-)
> Argh :)
>> Nothing prevents us from having e.g. a FileGenerator and a
>> CacheableFileGenerator if we want to move all the caching stuff into its
>> own module. Or do I miss something?
> Yes, that is an option which I immediately disregarded :) The problem I
> see is switching from non caching to caching. If you think of the old
> Cocoon sitemap, you define shorts names for the components, so you map
> "file" to the file generator. First question in this case is, which one
> (the caching or the non caching)? Do you want to define short names for
> both versions and then decide inside your pipeline? 

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.

> This is too
> complicated as you already have to choose the correct pipeline
> implementation.
> And we double the number of classes just to have something optional.

yes, that's the downside of my proposal.

> Perhaps we can come up with some auto-caching functionality? The full
> configuraion of a component is used to make up the cache key and if one
> of the parameters is a url we do the content modified check for this
> url. (Just a first brain dump, so this certainly needs some tweaking).
> E.g. the file generator does not need to implement any special stuff for
> caching - it just works. If a component needs special handling it can
> implement the optional CachingPipelineComponent.

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.

                                   - o -

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).

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message