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: local policy)
Message-ID: <496CDFD1.3060509@indoqa.com>
Date: Tue, 13 Jan 2009 19:39:13 +0100
From: Steven Dolg <steven.dolg@indoqa.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [C3] Pipeline component event types
References: <49520644.30108@gmail.com> <4955F707.4020705@apache.org>
 <200812271413.43183.andreas.pieber@schmutterer-partner.at>
 <4956B9B2.7050300@apache.org> <495725CD.9050809@indoqa.com>
 <49576FCD.60902@apache.org> <495775FC.6060606@indoqa.com>
 <4957E5CF.2090307@apache.org> <49691C70.6050205@tuffmail.com>
 <002e01c974af$bcb64350$3622c9f0$@spoerk@gmx.at>
 <496BADE1.1070300@tuffmail.com> <496C60FC.9040203@apache.org>
 <496C8B35.3060700@tuffmail.com> <496C8C84.6080002@tuffmail.com>
 <496CA061.3000700@apache.org> <496CD798.5000704@apache.org>
In-Reply-To: <496CD798.5000704@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Carsten Ziegeler schrieb:
> Reinhard Pötz write:
>   
>>>> Agreed. How do you know what kind of wrapper do you need if you don't
>>>> know what kind of events components consume and produce?
>>>>         
>> My assumption is that the developer that uses the pipeline knows what he
>> does.
>>     
> :) While this assumption *should* be true, we all know that in most
> cases it is not. So I fear many people will stumble across this problem.
>
> But I have one question: if we don't allow to mix different event types
> in a single pipeline (and I guess by event types we mean sax, dom, stax)
> why do we have a generic pipeline interface?
>
> Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a
> stax pipeline, perhaps sharing a common interface?
>   
 From my point of view:
Currently the user must know which components he needs (as in "I want to 
process XML and I'd like to do it with StAX").
As soon as he know this, he just selects the components (either existing 
or created) but them in *any* pipeline (caching/noncaching/etc.)
Done!
If he feels that he needs that little extra performance and can handle 
it in SAX as well: just change the components - Done!


If there were multiple, content-specific Pipelines he still needs to 
know which components, but also which type of Pipeline.
If he feels the need to change to SAX (so a switch in the "event type" - 
IMO a sub-optimal term, since not every component actually passes nice 
events like StAX does) he also needs to change the Pipeline.
This may seem easy now, but imagine a larger system. Changing the 
pipeline type can be challenging there.

And what about automatically generated pipelines (e.g. the sitemap).
This will be so much harder as you have to collect and analyze all 
components first before you can actually build the pipeline to use.


Defining a common interface for different pipeline types does not really 
change this.
If the common interface is sufficient for handling and operating the 
pipeline they are exchangable (from the callers point of view) and 
provide the same environment we have now.
If the common interface is not sufficient for handling and operating the 
pipeline it is merely a marker interface and it probably wouldn't make 
much difference. (Although it is still useful for declaring parameter 
types, etc.)


I may be biased here ;-) but I have yet to see the benefits of different 
pipeline types...

Steven
> Carsten
>
>