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.
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.
I strongly agree that the flow layer needs testing.
But I have to tell you the main reason I started proactively adding features recently is that few people seemed to be able to use it in its current state.
Even now I see a lot of "you've done a great job with the flow, but I've never actually tried it".
If you're right that it's just a lack of documentation then let's correct that.
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.
Has anyone (besides me) actually tested the xmlform-flow integration or velocity integration? I haven't received any feedback.
This means that I would like to see flow-database stuff removed from the main trunk.
I can do that, but I'd prefer to move it elsewhere in the main trunk where people could still use it to get started with using the flow layer.
Look, I work for an Enterprise Application Integration company. I know what it means to build large-scale applications and I think I know what's brain dead and what isn't. That's not the point. The purpose of the database api wasn't to show off, or to provide a brain dead solution for building large scale applications, but instead to lower the immediate barrier to entry of the flow layer so that more people would use it - and test it.
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.
Yet, the simplicity of adding stuff with the flow layer and its object model should *NOT* trigger easy solutions to complex problems just for show off, like this database flow layer does.
Regards, Chris
