Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 14316 invoked by uid 500); 2 May 2003 08:31:18 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 14281 invoked from network); 2 May 2003 08:31:18 -0000 Received: from unknown (HELO mail.dff.local) (62.159.19.130) by daedalus.apache.org with SMTP; 2 May 2003 08:31:18 -0000 Received: from altair.dff.local ([172.16.2.8] helo=dff.st) by mail.dff.local with esmtp (Exim 3.35 #1) id 19BVx3-00087F-00 for cocoon-dev@xml.apache.org; Fri, 02 May 2003 10:31:29 +0200 Message-ID: <3EB22D65.9090903@dff.st> Date: Fri, 02 May 2003 10:33:41 +0200 From: Torsten Curdt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [VOTE] allow redirects in handle-errors References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I think, the only viable solution is b) and adding a redirect-action > to the core :) ...but isn't this also "promoting" redirects? If someone seriously needs to redirect - what about telling him "do it in an action - but don't tell anybody". IMO we just shouldn't make it too easy. So often we are concerned... SoC here and there... Some things could be really easier if we would go for it. But I thought we don't wanna go down this trail and resist the evil temptations ;-) ...just because we (think we) *know* it's right or wrong on the long run... -- Torsten