cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: [c3] Pipeline results
Date Wed, 14 Jan 2009 00:15:23 GMT
Grzegorz Kossakowski schrieb:
> Steven Dolg pisze:
>   
>> 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.
>>     
>
> Processing input and generating output is a common to all pipeline components. For any
meaningful way of using
> components you need methods that will execute given component. If we were to stick to
this interface it should be
> renamed to something like PipelineComponentBase but this obviously does not solve anything
more than we are honestly
> admitting our mistake here.
>
>   
>> 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 you were unable to check what I've come up with (btw. GitHub folks have fixed their
problem already so links work) so
> you couldn't get my point. Just have a look at reworked PipelineComponent interface which
should be considered as a
> starting point for a discussion.
>
>   
>> 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.
>>     
>
> In pipeline we have three types of components: generators, transformers and serializers.
Could you explain to me why do
> we need 5 different interfaces supporting these three cases:
>   PipelineComponent, Starter, Producer, Consumer, Finisher
>   
We have 5 interface because those are the 5 "roles" any pipeline 
component can have.
There are those that can be the first component of a pipeline: Starter.
... the last component of a pipeline: Finisher.
... providing input for a following component: Producer.
... receiving input from a preceeding component: Consumer.
All are components that can be configured and added to a pipeline: 
PipelineComponent.

IMO it makes sense to really have those 5 interfaces, because not all 
Starters are actually Producers, not all Consumers are Finishers, and 
not all Producers are Consumers as well.
There are even components that are Starters and Finishers at the same 
time (e.g. the FileReaderComponent).
We could very well define all possible combinations but that would not 
reduce the number of interfaces.

> Moreover, we have AbstractGenerator, AbstractTransformer and AbstractSerializer. An argument,
that in C2.2 it wasn't
> simpler is rather weak as we strive for finding a *better* design. It's not about pointing
at anyone and blaming about
> imperfect code (because you could easily do the same for me) but about expressing current
weak points and discussing
> possible solutions.
>   
Maybe it is a weak argument. But it is an argument nonetheless.
Actually it is quite hard to compare a working solution that is actually 
already in use with an approach that is yet to be converted into a 
working piece of software.
So yes, I prefer to compare it to Cocoon 2.2.

>   
>> 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...
>>     
>
> We can disagree on different things and it's ok but accusing me of choosing random pieces
of code just for a sake of
> criticizing is not ok.
>   
Well the interface PipelineComponent alone may look weird.
But the Pipeline API contains some more code.
Looking at how the other interfaces (Starter, etc.) are used should 
indicate what they are used for.

The SAX components in addition to the StAX components should demonstrate 
why there is little sense in having content type related methods in the 
PipelineComponent.
Because the idea behind the Pipeline API is that the components decide 
how they communicate with each other. Thus the Pipeline API must not 
make any assumptions about this.

The intention was to have a pipeline that is flexible enough to support 
different content types and still makes it easy enough use them and 
actually create new ones.
The recent experiences with StAX made me believe that the current 
implementation achieved that goal pretty well.
Having a user implementing some new generators and serializers - 
practically all on his own - supports this impression.

Of course there are still points that can (and should) be improved - 
there always are.

> I've worked with this code, I have reworked it according to different philosophy to show
possible benefits and
> weaknesses. After that, I've come to conclusion that this interface looks weird and found
relation to problem discussed
> in this thread (pipeline results). I wanted to bring that interface to the attention
because we still have quite a lot
> of people much clever than me on this list that could possibly propose something better.
>
>   


Mime
View raw message