Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E648055.70203@anyware-tech.com>
Date: Tue, 04 Mar 2003 11:30:45 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Stabilizing flow in order to release
References: <3E645F29.4030007@apache.org>
In-Reply-To: <3E645F29.4030007@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

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