Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E645F29.4030007@apache.org>
Date: Tue, 04 Mar 2003 09:09:13 +0100
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030202
MIME-Version: 1.0
To: Apache Cocoon <cocoon-dev@xml.apache.org>
Subject: Stabilizing flow in order to release
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

Cocoon's phylosophy has always been to provide you with the "least" 
amount of degrees of freedom that you need to solve your problems. The 
fact that Cocoon still provides several solutions to the same problem is 
partially historical (think actions and, partially, xsp), partially 
endemic: some problems require enough complexity that somebody will 
factor it out and abuse it in different contexts.

We managed to keep the complexity of the sitemap to the bare minimum 
amount of semantics that we needed and we also managed to separate the 
concept of managing the states (resources) to that of managing the 
transitions (app flows) in a totally distinctive and completely 
orthogonal way.

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.

Why? well, everybody knows that writing SQL into your code is bad since 
it ties you to your database. Adding SQL and javascript is a potentially 
incredible RAD tool, but it's potentially horrible down the road, 
requiring huge maintenance costs to operate.

People don't like to write java code to do the glue between objects and 
relationals, but this doesn't mean that we have to remove the need for a 
decoupling between the business logic and how it is currently implemented.

Also, we don't have a real documentation of what's there in the flow.

*THIS* is the real showstopper and without documentation we don't even 
know if the flow is abusing parts of Cocoon that could lead to potential 
design vulnerabilities (also security!) that might be hard to fix in a 
back-compatible manner in the future.

So, while I'm all excited about this flow layer, I'm also scared (like 
Sylvain) about the fact that little is known and a lot seems magic.

I don't want this to sound like a critic to Chris and his outstanding 
work and support on this, but the flow is becoming a critical piece of 
Cocoon 2.1-dev, just like the sitemap is, and exactly like nobody adds 
sitemap tags without *MAJOR* proposal/RT cycles, I would like to start 
protecting the future investiment of our users by doing the same on the 
flow and by protecting his object model.

                                      - 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.

2) each and every single FOM (Flow Object Model) object, method and 
property must be documented and then voted upon.

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.

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]

This means that we have to stop adding stuff and starting thinking if 
what we have is solid enough to stand the beta test and if we are 
confortable enough to start 'guaranteeing' back compatibility in future 
changes.

Please, place your comments.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------