cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: From Woody to CocoonForms
Date Sat, 06 Mar 2004 09:09:10 GMT

Why the "c" must means something? I think we are missing the point here.
The idea of "CForm" is to allow easy searching on the Net for Cocoon form.
Just googling:

Form:   133 M
CForm:  28.4 K
CForm1: 180
CForm2: 153

If the "C" must means something, then choose: "cool", "creative", "coocon"
or any other. It can be a "tag" to help user find our stuff on the net.

What about the next release?

We can call it CForms 2.0, etc. Just the same as cocoon evolves our forms
can evolve. Think what have in common Cocoon 1.0 and Cocoon 2.2? Almost
nothing, even the target was changed from a publisher framework to a web
development framework. It is natural to move the target on the time.

Now I understand why MS tell that OSS project don't innovate:

Look at then, they are rewriting a similar tool as Apache Ant, but it is
not called MS Ant, it is called MS Builder.

Can you see the innovation in the name? New name means innnovation. :-D

In short, I am +1 to have a clear name for our form-fw: "CForms".

Best Regards,

Antonio Gallardo

Ugo Cei dijo:
> Marc Portier wrote:
>> another +1 to 'cforms' over 'forms'
> Doesn't the "c" stand for "Cocoon"? If it does, I find it somewhat
> redundant, especially in a package name: org.apache.cocoon.forms ==
> org.apache.cocoon.cocoon.forms?
> And what if someday we develop a new forms framework, do we call it
> "dforms"? ;-)
> I propose to use just "forms" as the block name, "Cocoon Forms" in the
> docs, and do a s/woody/forms/ in the package names and namespaces.
> Just MHO,
> 	Ugo

View raw message