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".
Adapting to better reflect historical accuracy: no single line of Woody was written until _after_ Bruno's form proposal was discussed on the list. So in the end, the proposal was about design, and not about a finished code package being donated to the project. I tend to believe that this is exactly the reason why Woody has been able to grow into Cocoon Forms.
[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.
+1 - let's go for "Cocoon Forms" - even if I feel kind of sad seeing the name I suggested going away. Oh well - it's about seeing you kids grow up, I guess.
Bearing in mind the amount of work that requires a _real_ renaming, like changing package names, namespaces and all that - who's going to do that?
Cheers,
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
