Some like the flow, some don't know it enough to dislike it but won't try it out until we have a release. In the meanwhile, we are adding functionality without stabilizing it.
... and some would really like to use it but are stuck on other matters that prevent them to do it :-(
I believe we should work toward release Cocoon 2.1, this is our priority at the moment: restore a saner and faster release cycle, possibly much better integrated with continous integration and unit testing.
Now: I considered lack of callable pipelines and lack of xmlform-flow integration and lack of velocity views all showstoppers, now we have it so I'm calling a feature freeze of the flow layer for Cocoon 2.1, plus internal redesign to match the points that Sylvain outlines.
This means that I would like to see flow-database stuff removed from the main trunk.
While I really appreciated Chris' effort to provide a solution to the data connection problems we will be facing, I think that providing a braindead way to 'write SQL into your flow' is *EXACTLY* what I don't want to see.
I'm not so strict about that : refer to my answer to Christopher : we need some *optional* stuff like that one to lower the entry cost to people that are not used to "programming in the large" (especially non-large projects).
Leaving a bit the purely technical matters, having such RAD features is also good when you want to convince people having a {AS,JS,PH}P background to migrate to Cocoon or for training sessions where the available time - or trainees knowledge - doesn't allow the deployment of a full-featured O/R tool for hands-on exercises.
<snip/>
- o -
This said, let me write down a list of things that have to happen before we can safely consider the flow ready for release:
1) Sylvain's complains about the abuse of the Environment must be resolved.
I'm happy to see that as the main priority ;-)
2) each and every single FOM (Flow Object Model) object, method and property must be documented and then voted upon.
Agree. We also have to find a solution for "flow blocks" so that flow features can be augmented without interfering with the main trunk.
3) no higher level functionality should be added without a previous RT/proposal/vote cycle.
I'm perfectly aware of the fact that this will reduce the freedom of people like Chris to innovate and show potentially creative new uses of the flow. For this reason I'd add that:
4) everybody is allowed to write flow-related stuff in the scratchpad without the previous RT/proposal/vote cycle, even if they are strongly encouradged to do so anyway to foster communication and creative discussion.
Being able to structure flow (or JS ?) features in blocks is IMO the key for having a stable foundation without discouraging creativity.
Anyway, the point I want to come across is the following:
Cocoon is committed to provide a solid foundation for people to work and operate. Currently, Cocoon 2.1-dev is alpha, means that we can change things around without noticing and without allowing people to complain because we warned them and we want to have the complete freedom to innovate.
At the same time, Cocoon 2.1-dev has to reach beta state ASAP since we are nearly feature complete and our internal cleanups and refactoring are working very well. [in a followup I will outline what's missing before release]
C2.1 isn't even alpha ! We should first issue some alpha releases to show people that stabilization is on the way and they can start looking at it and even using it. This will drain comments and help use to strengthen the beta version.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
