cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinhard_po...@gmx.net>
Subject RE: [RT] the value of being wrong
Date Tue, 15 Jul 2003 16:33:46 GMT

From: Stefano Mazzocchi
> 
> 
> 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 
> suggests).
> 
> Sylvain is calling for cleaning up the abstractions to allow 
> people to 
> experiment without having our core being biased toward a particular 
> solution.
> 
> 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)

Or maybe much simpler: Writing a new sitemap implementation needs much
more knowledge in Cocoon internals than writing a form implementation 
(no offense, it's only my personal impression and speaking from my
personal knowledge ;-)

> 
> 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 
> needs.
> 
> It is evident, thru the recent heated discussions, that the current 
> flow implementation doesn't share that. Neither did the form handling 
> approaches.
> 
> 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.

+1000 

This has the reasons you pointed out but also marketing reasons. If I
talk in 6 months about Cocoon Flow and we have 3 different
implementations
which are called "official" a brand would get diluted (hope that's
correct
the German word is "verwässern" - maybe somebody with better
English/German
skills can confirm it or translate it better).
But there is no problem if people implement their own controllers for
*their*
projects.

> 
> 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.

Ready for a vote on this?

"
So why don't you make a compromise by:
* Renaming like Sylvain and Marc suggested (and many agreed)
* Keep only one implementations (JavaScript) as the official one
* Allow alternative experimental implementations
* Let Darwin do the rest ;-)
"

> 
> 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.


6) You opened (at least) my eyes that technical elegance is not
always the best and that in OS there are more important things. 

And I think many of us will be more careful with second, third
and fourth, ..., implementations which all do the same ...

Cheers,
Reinhard

> 
> 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 
> implementations.
> 
>  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.
> 
> --
> Stefano.
> 


Mime
View raw message