cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [c3] Pipeline results
Date Tue, 13 Jan 2009 21:36:57 GMT
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

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.

> 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.

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.

Best regards,
Grzegorz Kossakowski

View raw message