Return-Path: Delivered-To: apmail-jakarta-avalon-apps-dev-archive@apache.org Received: (qmail 10397 invoked from network); 16 Aug 2002 20:36:52 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Aug 2002 20:36:52 -0000 Received: (qmail 2970 invoked by uid 97); 16 Aug 2002 20:37:21 -0000 Delivered-To: qmlist-jakarta-archive-avalon-apps-dev@jakarta.apache.org Received: (qmail 2954 invoked by uid 97); 16 Aug 2002 20:37:21 -0000 Mailing-List: contact avalon-apps-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Applications Developers List" Reply-To: "Avalon Applications Developers List" Delivered-To: mailing list avalon-apps-dev@jakarta.apache.org Received: (qmail 2942 invoked by uid 98); 16 Aug 2002 20:37:20 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Berin Loritsch" To: "'Avalon Applications Developers List'" Subject: RE: InfoMover Interfaces: the Proposals Date: Fri, 16 Aug 2002 16:36:39 -0400 Message-ID: <003501c24564$9f9abe80$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: kevin.s.ruland@mail.sprint.com > > Berin, > > How could this support a "fork" in the pipeline. Say the same data > needs to be put in two different formats in two different files? > > Assume of course, that transactionality is not an issue. > > By doing the chaining thing, one could define a sink which does the > fork and passes the data on to both sides. In order to fork the pipeline the Job would need to know how to do that, and have the forked pipelines processed by a thread. Keep in mind that Transactionality *is* an issue, and more importantly for InfoMover our efforts are concentrated on *MOVING* data, not altering it. The spirit of the Manipulator is not to provide industrial strength manipulations or transformations, but to fill in the missing pieces of data, or to validate the information as it comes across. With this limitation, forked pipelines are really not all that great-- and more importantly it is really flexibility syndrome. For the first version we really have to KISS (Keep It Simple, Stupid). My focus is to teach how to write component based software--not provide a swiss army knife. All that can happen later as we find its shortcommings and have new uses for it. I am responding to your other post, so look for it soon. -- To unsubscribe, e-mail: For additional commands, e-mail: