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.
