Re: [vote] FOM design methodology
On Sun, 15 Jun 2003, Stefano Mazzocchi wrote: 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? #2 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? +1 I'm late, I know ;-) Giacomo
Re: [vote] FOM design methodology
Giacomo Pati wrote: I'm late, I know ;-) But welcome anyway!
Re: [vote] FOM design methodology
On Sun, 15 Jun 2003, Stefano Mazzocchi wrote: 2) small to big +1 Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 Orixo alliance: http://www.orixo.com/ Web:www.luminas.co.uk
Re: [vote] FOM design methodology
2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 simplest thing that could possibly work.
RE: [vote] FOM design methodology
-Original Message- From: Tony Culshaw [mailto:[EMAIL PROTECTED] Sent: 16 June 2003 18:10 To: [EMAIL PROTECTED] Subject: Re: [vote] FOM design methodology I've considered using in in the past for a project and then rejected it as being in the api too unstable basket. Hah! I'm already using albeit a tiny example of it in production. 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. So likewise to save me future work! [+1] small to big. [-1] big to small. Christopher
RE: [vote] FOM design methodology
Need it be either/or? (This is a possibly a naive question, but you wanted feedback!) Could there be a 'solid' and an extended 'experimental' contract? Solid would be 'written in stone', nothing could be removed from it. Experimental would have _additions_ to the basic contract, would have scratchpad status, and be clearly marked as subject to revision, until natural selection took its course one way or the other, i.e. the extensions deprecated or included in solid. But if it's either/or, then small_to_big +1 with the reservation that things get dreamt up by pure mathematicians for their own sake that subsequently engineers make use of.
RE: [vote] FOM design methodology
Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 Carsten
Re: [vote] FOM design methodology
Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 Ciao, -- Gianugo Rabellino Pro-netics s.r.l. http://www.pro-netics.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [vote] FOM design methodology
Carsten Ziegeler wrote: Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 +1 -- Torsten
Re: [vote] FOM design methodology
2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 regards Jeremy
Re: [vote] FOM design methodology
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 :-) 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/
RE: [vote] FOM design methodology
At 03:58 AM 6/16/2003, you wrote: Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1
Re: [vote] FOM design methodology
Tony Culshaw wrote: 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. I agree.
Re: [vote] FOM design methodology
Stefano Mazzocchi wrote: 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. +1 for big to small
Re: [vote] FOM design methodology
On Mon, Jun 16, 2003 at 09:58:10AM +0200, Carsten Ziegeler wrote: Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 Here is my +1 Michael Carsten
Re: [vote] FOM design methodology
2) small to big +1 from me Ricardo Rocha wrote: Stefano Mazzocchi wrote: 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. +1 for big to small But this *must* be an error ;-) The FOM design that was proposed by myself and Ricardo follows methodology #2. Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
Re: [vote] FOM design methodology
Joerg Heinicke wrote: 2) small to big +1 from me Ricardo Rocha wrote: Stefano Mazzocchi wrote: 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. +1 for big to small But this *must* be an error ;-) Sure it is, shom! :-) So I stand corrected: +1 for small to big The FOM design that was proposed by myself and Ricardo follows methodology #2. Joerg
Re: [vote] FOM design methodology
On Sun, 15 Jun 2003, Stefano Mazzocchi wrote: 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 -0 #2 +1! Giacomo
Re: [vote] FOM design methodology
Stefano Mazzocchi dijo: 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? From a security point of view the answer is clear: 2 From a developer point of view I think: 1 Really, to answer this question is dificult. :) Antonio Gallardo
Re: [vote] FOM design methodology
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.
Re: [vote] FOM design methodology
On Sunday, June 15, 2003, at 07:31 PM, Stefano Mazzocchi wrote: 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 -pete
