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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
