I've considered using in in the past for a project and then rejected it as being in the "api too unstable" basket.
Anything that ensures code that I cut now won't break later and has more of a future gets my vote. [+1] small to big. [-1] big to small. ----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 15, 2003 4:31 PM Subject: [vote] FOM design methodology > The FOM is the API contract between the flowscript and the rest of > Cocoon. In the next few years, I believe that the FOM and the sitemap > semantics will be recognized as the single most important contracts in > Cocoon. > > Solidity and well behaved evolution of those contracts will be vital to > the success of Cocoon, expecially in industrial environments where > software has to be maintained for decades (as it is the case in many > cocoon installations today) > > 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? > > if it is different from the one actually in use in the actual version of > the FOM, would you like to see the FOM changed as to follow your > preferred methodology? > > Please place your vote. > > NOTE: even if you are not a user of the flow, your feedback is important > and will be appreciated. > > Thank you. > > -- > Stefano. > >
