cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 20:00:26 GMT
Nicola Ken Barozzi wrote:

> Stefano Mazzocchi wrote, On 13/07/2003 19.56:
>> I like this thread. It might seem a little 'accademic' to talk about  
>> all these things so openly and, for sure, many of these things tend 
>> to  be rather subjective, thus harder to find rational consensus on.
>> The result of this thread may not be an objective guideline, but I'm  
>> glad we are presenting different views and design strategies on the  
>> table because, at least, we know what other people feel about these  
>> things and we can forecast future friction and, hopefully, prevent it.
> <snip/>
> I agree. Here are my 2c based on what I have seen and lived in Avalon.
> 1 - Keep only one implementation. Have all work on that. This means 
> that since we decided to use the flow based on javascript, we should 
> pursue that. This helps in keeping the project focused and prevents 
> endless discussions about things that have *already* been decided.
> 2 - Do not prevent others from building alternatives. This is why I 
> like the sandbox: it keeps mutations happening, and also keeps them 
> away from the main code.
> 3 - Routinely evaluate mutations and decide if it's worthwhile to keep 
> them by integrating in the main branch or deleting them. This is what 
> till now we have failed to do, but is important for (2).
> 4 - There is no need to block others from building alternative 
> implementations, so "pluggable" engines can be used. Look at the 
> current Processor pluggability... who has used it? I reckon that it 
> will simply help us down the road to change it if necessary. The 
> important thing is that these possibly different implementations 
> should not reside in the Cocoon CVS (except in the sandbox, with 
> routine checks as per point 3).
> Avalon has gone down this path. We have decided that we will keep as 
> the Avalon container only one implementation. This does not prevent 
> others from building Avalon-based containers. Also all the 
> experimantal code is in the sandbox, and is being evaluated very 
> frequently for inclusion in the main code.
> So, in the end, if someone wants to make a FSM engine of the Cocoon 
> flow, I'm ok with it. We can also make it pluggable, so others can 
> make them if they have good time to use.
> Just not here, as we have decided for the javascript flow, and we must 
> pursue a single direction. Endlessly discussing about changing 
> something that is not finished only creates unnecessary deviations.
> Therefore, I encourage whoever has different implementations and 
> really believes in them not to desist and keep on using them, but with 
> the knowledge that it's a different implementation and that it will 
> not reside here for quite some time, if ever. 

I fully agree with all that you said, and Avalon's experience can be 
very valuable, as that's from problems and crisis that we really learn 
how to proceed.

Now, I repeat it once again, I don't want to change the JS flow. I just 
want other experiments and implementations to be possible. These 
experiments and implementations need not be in Cocoon's CVS (or else, be 
in the scratchpad). I just proposed to rename a few classes so that 
these experiments could be possible without "distorting" the meaning of 
existing flow-related classes.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message