cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [Corona] PIpeline API
Date Sun, 13 Jul 2008 14:27:36 GMT
Carsten Ziegeler wrote:
> Hi,
> I'm currently looking for a nice and simple pipeline api to be 
> integrated with Apache Sling :)
> And of course I had a quick look at Corona (as everything else I found 
> was not what I was searching for) which would be the prefered way of
> implementing pipelines :)


> Now, I only need the naked pipeline stuff - and most important here are
> the interfaces and perhaps a simple pipeline implementation (without 
> caching).
> There are some points I would like to discuss:
> a) Simple API separated from the implementation
> I think it makes sense to put all API stuff into one single package, 
> these are only a handfull of classes - perhaps there might be an 
> additional util package.
> The implementations of the various components should go into a different 
> module as they are not needed by everyone. At least they should be in a 
> different package for modularization purposes.
> I would also package the whole caching stuff into an own module.

I agree with you that the package structure should be cleaned up. It's 
also a good idea to create a 'corona-pipeline-sax' module that contains 
the SAX based components. I'm not so sure if we should really move the 
pipeline implementations into their own modules. This seems to be too 
much modularization for my taste. (The corona-pipeline.jar, that 
currently contains the SAX components, is about 70kb only.)

> b) Actions should not be part of the pipeline api
> I think we discussed this some time ago :) Removing actions from the 
> pipeline stuff does not really hurt - they are invoked before the 
> pipeline, so it shouldn't be too hard to build custom code which 
> collects actions, assembles the pipeline, invokes the actions and then 
> the pipeline.

no objection ;-)

> c) Pre and post processing
> As the pipeline interfaces are not tied to sax or any other model (which 
> is ok), there is no explicit notion of indicating that the processing 
> starts or is finished - the latter is especially interesting for 
> cleanup. So I think we should add these two lifecycle methods to the 
> pipeline component interface.

I don't see any problem either. Being curious, what are your use cases?

> d) Splitting setup and execute
> I would like to split the Pipeline#execute method into two, one for 
> initialisation and one (without arguments) for executing.

I was thinking about this myself because we need this separation also to 
optimize conditional GET operations when the servlet URLs are involved.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

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

View raw message