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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
________________________________________________________________________
