From dev-return-101018-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Jan 13 12:44:22 2009 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 87547 invoked from network); 13 Jan 2009 12:44:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jan 2009 12:44:21 -0000 Received: (qmail 37397 invoked by uid 500); 13 Jan 2009 12:44:20 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 37327 invoked by uid 500); 13 Jan 2009 12:44:20 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 37318 invoked by uid 99); 13 Jan 2009 12:44:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Jan 2009 04:44:20 -0800 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates 216.86.168.178 as permitted sender) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Jan 2009 12:44:12 +0000 Received: from [10.1.1.61] (unknown [193.0.96.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2AD0D23E499 for ; Tue, 13 Jan 2009 07:43:50 -0500 (EST) Message-ID: <496C8C84.6080002@tuffmail.com> Date: Tue, 13 Jan 2009 13:43:48 +0100 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.9 (X11/20071220) 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> In-Reply-To: <496C8B35.3060700@tuffmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Grzegorz Kossakowski wrote: > Reinhard Pötz wrote: > >> I don't believe that pipelines should contain components that support >> different event types or that we event need components that have >> different input and output events. >> >> > What about serializer? Usually, it produces events of a type different > from the type of events it consumes. > >> If you want to mix your components (e.g. using a SAX component in a >> pipeline full of StAX components), you should put your 'alien' component >> into a wrapper. >> >> > 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? > > How component can be sure that next component (its consumer) is the one > that accepts right type of events? By checking using instanceof? > My point is that once we agree to have generic pipelines that can take > components accepting/producing any kind of events then we need to invent > some mechanism that check if pipeline is built correctly. It shouldn't > be a concern of a given component. > > If we agree on above point, then my suggestion would be to look for a > way that pipeline-correctness is ensured by compiler. > One more thing: The idea that pipeline does know about event types that components process solves the problem with pipeline results as you have different event type carrying different data. -- Best regards, Grzegorz Kossakowski