Hi: 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. <joke> 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 </joke> 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 >
