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 :-)
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
------------------------------------------------------------------------ -
Stuart Roebuck [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
