Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.183 as permitted sender)
Message-ID: <496D0979.3070309@tuffmail.com>
Date: Tue, 13 Jan 2009 22:36:57 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [c3] Pipeline results
References: <49509326.3030108@apache.org> <49509520.6010603@apache.org>
 <4950A130.2080702@apache.org> <4952467C.10303@apache.org>
 <49589C61.7080200@apache.org> <4960B5A3.5070008@apache.org>
 <4961C6A8.5000705@apache.org> <49623399.6050408@apache.org>
 <49624116.3020009@apache.org> <496301FB.3010608@apache.org>
 <496609EB.3040804@apache.org> <496884CC.8040203@tuffmail.com>
 <49689550.5080608@apache.org> <496BB17A.1080802@tuffmail.com>
 <496CDBCE.4030805@indoqa.com>
In-Reply-To: <496CDBCE.4030805@indoqa.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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