cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] the value of being wrong
Date Tue, 15 Jul 2003 15:48:01 GMT
I have taken a step back and reconsidered the whole discussion about 
flow and how to implement it. I still believe that there is a lot of 
preconceptions against the use of a scripted flow with continuations, 
but diversity is a better value than any implementation (as Berin 

Sylvain is calling for cleaning up the abstractions to allow people to 
experiment without having our core being biased toward a particular 

This is aligned with the spirit that cocoon has been using so far.

At the same time, since I consider the flow control (not the "scripted 
flow with continuations", but the general abstract concept) a very 
important piece of the cocoon system (just like the sitemap) I wanted 
people to concentrate and discuss on a particular implementation 
instead of branching off their own vision.

This has happened with the form handling approach but didn't happen 
with the sitemap.

Sylvain points out that the reason why it didn't happen with the 
sitemap is that, being a generally new and specific concept, there was 
no community pressure for more than one implementation (despite the 
continous call for pipeline dynamic assembly, which has been 
continously challenged and never implemented)

Sylvain goes on saying that the reason why the sitemap (even if the 
architecture allows pluggability) remained unique might not be due to 
our protection but only to up-front fittability of the environmental 

It is evident, thru the recent heated discussions, that the current 
flow implementation doesn't share that. Neither did the form handling 

I am reconsidering my -1 on the attempts to make the flow hooks in the 
sitemap more abstracted and I'm turning it into a +1. I will put some 
technical comments on the original thread, but I wanted to show why I 
changed my mind.

I still believe that there should be only one official implementation 
for core functionalities that cocoon ships. One for the sitemap, one 
for the flow controller, one for the form handling mechanism.

The reason for this is:

  1) focus documentation and users
  2) force developers to talk and void subculture creations for 
important parts of the framework
  3) allow alternatives implementations to reside in a scratchpad area 
or as scratchpad blocks (yet to arrive, but for sure they will, 
expecially with real blocks)

This should balance the need for evolution (asked by developers) with 
the need for stability (asked by users).

Finally, you are probably noting that I'm basically stating exactly 
what Andreas Hochsteger suggested as a compromise.

Mani kudos to him for his wisdom and balanced suggestion.

At the end, I would like to note that I consider these discussions very 
healthy because:

  1) people express their comments, their visions and their agendas. 
This is not always the case without a litte bit of pressure.
  2) consensus is searched and, when reached, stabilizes the vision of 
the entire community further.
  3) compromises help balancing the result of the community development, 
providing the darwinistic equivalent of death: which selects the 
fittests to environmental constraints.
  4) if the line of fair discussion is crossed, people have a chance to 
learn, understand and apologize. This gives a human touch that goes 
past work collaboration and creates deeper relationships, that normally 
reflects in real life (read: friendship. I'm writing this from a 
friend's house met thru cocoon residing on the other side of the world 
from my hometown. And other people are mixing vacation time with 
real-life meeting with cocoon people right as we speak. I think this is 
another thing that makes this community special)
  5) this community values admitting mistakes or apologies more than 
being right. The community building and stabilizing effect of this 
simple approach to disagreement MUST NOT be underestimated, nor limited 
in any way or changed.

To sum up and I've said this in the past already: it is more useful to 
be wrong than to be right, because you have the chance to learn 
something only when you are wrong.

But there is more: being wrong is something that you might know, but 
fail to express, for ego preservation. This prevents others to 
understand that you understood and learned. This prevents others from 
respecting you more as a human being.

So, let me state it clearly: I think I understood that my balkanization 
concerns were overemphasized and that cocoon to be able to allow other 
people to continue R&D in the flow control area without being limited 
by the current implementation.

On the other hand, I do believe that this R&D should lead to a better 
single implementation rather than to a series of parallel competing 

 From the past threads, I believe the above two points sum up a general 
community consensus.

I will continue the discussion based on technical comments on the 
original Sylvain's thread.


View raw message