Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 51287 invoked from network); 18 Oct 2004 13:49:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 18 Oct 2004 13:49:33 -0000 Received: (qmail 39816 invoked by uid 500); 18 Oct 2004 13:49:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 39722 invoked by uid 500); 18 Oct 2004 13:49:27 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 39708 invoked by uid 99); 18 Oct 2004 13:49:27 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [130.237.222.202] (HELO smtp.nada.kth.se) (130.237.222.202) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 18 Oct 2004 06:49:26 -0700 Received: from [192.168.105.46] ([192.58.197.171]) (authenticated bits=0) by smtp.nada.kth.se (8.12.10/8.12.1) with ESMTP id i9IDnNBD006218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2004 15:49:23 +0200 (MEST) Message-ID: <4173C9DE.2030108@nada.kth.se> Date: Mon, 18 Oct 2004 15:49:18 +0200 From: Daniel Fagerstrom User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Building ECM++ for 2.2 References: <200410180956.i9I9uCCO007970@mx3.nada.kth.se> In-Reply-To: <200410180956.i9I9uCCO007970@mx3.nada.kth.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: >I just started with this approach and could finish it in the next days >if people think it is worth going this way. It would give 2.2 more meat >as well. >But perhaps this idea is totally foolish? > >Thoughts? Comments? > > +1 Seem like a very reasonable way to go, we both takes care about backward compability and opens the possiblity to add functionality to the old one or plug in new and sexier component containers. We also get a smoother migration plan if we eventually would like to get rid of the old way of doing stuff. /Daniel