Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 49431 invoked from network); 6 Jul 2007 06:23:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jul 2007 06:23:40 -0000 Received: (qmail 79350 invoked by uid 500); 6 Jul 2007 10:33:39 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 79281 invoked by uid 500); 6 Jul 2007 10:33:39 -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 79270 invoked by uid 99); 6 Jul 2007 10:33:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2007 03:33:39 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2007 03:33:33 -0700 Received: from [192.168.0.129] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 0F180A3209 for ; Fri, 6 Jul 2007 06:33:11 -0400 (EDT) Message-ID: <468E1A5F.4020508@apache.org> Date: Fri, 06 Jul 2007 12:33:03 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: RT: map:call as generic non-redirecting controller code References: <4683DF1E.902@nada.kth.se> <884F6A4A-DA90-40FC-BFD8-351A0306CC45@nukinetics.com> <468B9869.8070206@nada.kth.se> <468BA762.9040405@apache.org> <468D63B9.6060008@nada.kth.se> <468E1570.8080904@apache.org> <468E19AC.3090704@weitling.net> In-Reply-To: <468E19AC.3090704@weitling.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Dev at weitling pisze: > > Time for my 2 cents, sorry: > To be able to put a function call anywhere in a pipeline would be great, > having access to all the variables defined up till then. To return data > to the pipeline for further processing via a special protocol doesn't > look like the best way to go (IMO). Functions should only return (in the > classical way) data to other functions calling them. Florian, I'm not sure if I understand you correctly. What's the use to return data from function call if you can't process it later? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/