cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Culshaw" <>
Subject Re: [vote] FOM design methodology
Date Mon, 16 Jun 2003 17:09:49 GMT
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" <>
To: <>
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.

View raw message