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
