cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 07:27:45 GMT

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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------




Mime
View raw message