Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 88571 invoked from network); 9 Oct 2003 13:38:04 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Oct 2003 13:38:04 -0000 Received: (qmail 13842 invoked by uid 500); 9 Oct 2003 13:37:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 13609 invoked by uid 500); 9 Oct 2003 13:37:56 -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 13596 invoked from network); 9 Oct 2003 13:37:55 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 9 Oct 2003 13:37:55 -0000 Received: (qmail 6112 invoked from network); 9 Oct 2003 13:37:54 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 9 Oct 2003 13:37:54 -0000 Date: Thu, 9 Oct 2003 15:37:53 +0200 Subject: Re: Renaming Woody to "Cocoon Forms" ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Stefano Mazzocchi To: dev@cocoon.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <20031009125008.GA15188@managesoft.com> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Thursday, Oct 9, 2003, at 14:50 Europe/Rome, Michael Melhem wrote: > On Thu, Oct 09, 2003 at 01:13:38PM +0200, Carsten Ziegeler wrote: >> Bertrand Delacretaz wrote: >>> >>> I think there was agreement on Monday about this, do we need a vote, >>> or >>> am I mistaken about the agreement? >> I think we had consensus, however not all committers attended the >> hackathon, >> so it might be that someone is -1 on it and has a good reason. >> >>> >>> Naming it "Cocoon Forms" is a nice parallel to "Cocoon Flow", and >>> shows >>> that we're betting the farm on it, which I like. >> +1 > > Im not against naming it "Cocoon Forms" but we need to be > sure we want to lock Cocoon to a single Forms implementation. I do. Just like I wouldn't want multiple flow, FOM or sitemap implementation as core. We allow other people to write their own, but we support only one of a kind: this forces discussions instead of forking... remember the balkanization thread. Which is a nice example, here, btw: the OT team proposed an alternative flow control concept and an alternative form framework, the community considered the first inferior to what we already had, but considered superior the second and promoted it as "official". [at the hackaton, there was a discussion on why the REST-based approach that Marc proposed cannot be matched one-2-one with the flow approach. Marc agreed that his idea of continuation and the current continuation are different concepts and forcing them into the same terminology might stretch the paradigm too much] No matter what the result was, I think forcing people with one solution forced discussions to happen, which helped all the parties involved, even to understand thing that were not previously understood by both sides. This is why having one official direction on the various areas is good(tm) and having a simple name for it "cocoon sitemap" "cocoon flow" "cocoon forms" would help our users to choose and feel more protected and a more solid foundation. -- Stefano.