cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject RE: [RT] the value of being wrong
Date Tue, 15 Jul 2003 17:15:23 GMT
Reinhard Pötz dijo:
> 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.

View raw message