cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: [c3] Pipeline results
Date Tue, 13 Jan 2009 18:22:06 GMT
Grzegorz Kossakowski schrieb:
> Reinhard Pötz pisze:
>> Thanks Grek! But there is no need to hurry because neither Carsten nor I
>> will work on this until Steven has finished his refactorings.
> Actually, for me there was a hurry as another series of exams in coming and I wanted
to contribute something useful
> before February.
> Your problem made me to analyze Cocoon3 Pipeline API very carefully and think about it
for a while. What I found rather
> strange is PipelineComponent interface, see:
> public interface PipelineComponent {
>     void setConfiguration(Map<String, ? extends Object> configuration);
>     void setup(Map<String, Object> parameters);
>     void finish(Exception exception);
> }
> Why I think this interface is strange (and confusing)? Becuase it does not deal with
the most important aspect of
> PipelineComponent: that it processes something and that it can be combined with other
components. The most important
> aspect is neither configuration nor setup of a component.
Configuration and setup is clearly not the most important aspect of a 
pipeline component.
But AFAIK interfaces are not designed by what is most important or not, 
but by what is common to the implementating classes and by what is 
really necessary for the caller of that interface.
 From that point of view configuration and setup (and yes, those names 
are not ideal - suggesstion are always welcome...) are very valid 
candidates for that interface.

It is the common basis of *all* pipeline components.
This is the most basic interface for any pipeline component - no matter 
if it is a Serializer, Generator, Transformer, uses SAX, StAX, Images, 
Beans, ...
I seriously wonder what methods for content processing and component 
linking you are missing at that level?

As this is basically a marker interface (with those 3 methods that are 
common to all components) a user won't have to deal with it.
Even a developer implementing new components hardly ever gets in contact 
with it, as he will usually deal with the Starter/Finisher, 
Producer/Consumer level above PipelineComponent.

I understand that this concept is quite a bit different than Cocoon 2.2 
and is almost completely undocumented at this time, too.
But I seriously doubt that selecting interfaces randomly and questioning 
their usefulness is really good approach...

> I started to think that we will have such problems like the one mentioned in this thread
as long as we don't address
> issues with PipelineComponent.
> I've decided to experiment with the code (after analyzing the problem on a paper) and
you can see results here:
> This code proves only one thing: that I failed to address an issue mentioned above. What
I'm interested in is if others
> share my concerns about PipelineComponent interface (and Pipeline itself) and if you
also see a relation to problem with
>  pipeline result?

View raw message