cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: [vote] FOM design methodology
Date Mon, 16 Jun 2003 10:53:54 GMT
As a normally voteless community developer/user:

On Monday, June 16, 2003, at 12:31 AM, Stefano Mazzocchi wrote:

> For this reason, I want to know the community feeling on the  
> methodology
> that should be applied to FOM design.
> There are two possible methodologies I see:
>  1) big to small -> give users all possible freedom and restrict that
> freedom once we understand potentially problematic usages.
>  2) small to big -> give users the least possible freedom based on some
> required functionality and grow as the users express their needs.
> The actual FOM design reflects methodology #1.
> The FOM design that was proposed by myself and Ricardo follows
> methodology #2.
> Now, the vote I ask is:
>  which methodology would you like to be applied?

+1 for small to big
-1 for big to small

As has already been well argued, the problems associated with removing  
API features from existing applications of Cocoon are too great to  
contemplate a "big to small" methodology.

If Cocoon has suffered from anything over recent years, it has suffered  
from excessive API growth and change, and it is critical at this stage  
that significant effort is placed on ensuring that it represents a  
platform upon which users can reliably develop and deploy now and  
painlessly grow with in the future.

I am very pleased to say that the transition from 2 to 2.1 has been  
managed with this in mind - a huge improvement over the necessarily  
difficult 1 to 2 transition.  So may it continue :-)


            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck  
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD  
Stuart Roebuck                          
Systems Architect                             Java, XML, MacOS X, XP,  

View raw message