Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Reply-To: <reinhard@apache.org>
From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <reinhard_poetz@gmx.net>
To: <dev@cocoon.apache.org>
Subject: RE: [RT] the value of being wrong
Date: Tue, 15 Jul 2003 18:33:46 +0200
Message-ID: <005301c34aee$dd0a0880$05506bc2@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <B730F944-B6DB-11D7-B6FE-000393D2CB02@apache.org>


From: Stefano Mazzocchi
>=20
>=20
> I have taken a step back and reconsidered the whole discussion about=20
> flow and how to implement it. I still believe that there is a lot of=20
> preconceptions against the use of a scripted flow with continuations,=20
> but diversity is a better value than any implementation (as Berin=20
> suggests).
>=20
> Sylvain is calling for cleaning up the abstractions to allow=20
> people to=20
> experiment without having our core being biased toward a particular=20
> solution.
>=20
> This is aligned with the spirit that cocoon has been using so far.
>=20
> At the same time, since I consider the flow control (not the=20
> "scripted=20
> flow with continuations", but the general abstract concept) a very=20
> important piece of the cocoon system (just like the sitemap) I wanted=20
> people to concentrate and discuss on a particular implementation=20
> instead of branching off their own vision.
>=20
> This has happened with the form handling approach but didn't happen=20
> with the sitemap.
>=20
> Sylvain points out that the reason why it didn't happen with the=20
> sitemap is that, being a generally new and specific concept,=20
> there was=20
> no community pressure for more than one implementation (despite the=20
> continous call for pipeline dynamic assembly, which has been=20
> 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=20
(no offense, it's only my personal impression and speaking from my
personal knowledge ;-)

>=20
> Sylvain goes on saying that the reason why the sitemap (even if the=20
> architecture allows pluggability) remained unique might not be due to=20
> our protection but only to up-front fittability of the environmental=20
> needs.
>=20
> It is evident, thru the recent heated discussions, that the current=20
> flow implementation doesn't share that. Neither did the form handling=20
> approaches.
>=20
> I am reconsidering my -1 on the attempts to make the flow=20
> hooks in the=20
> sitemap more abstracted and I'm turning it into a +1. I will put some=20
> technical comments on the original thread, but I wanted to show why I=20
> changed my mind.
>=20
> I still believe that there should be only one official implementation=20
> for core functionalities that cocoon ships. One for the sitemap, one=20
> for the flow controller, one for the form handling mechanism.

+1000=20

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=E4ssern" - 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.

>=20
> The reason for this is:
>=20
>   1) focus documentation and users
>   2) force developers to talk and void subculture creations for=20
> important parts of the framework
>   3) allow alternatives implementations to reside in a=20
> scratchpad area=20
> or as scratchpad blocks (yet to arrive, but for sure they will,=20
> expecially with real blocks)
>=20
> This should balance the need for evolution (asked by developers) with=20
> the need for stability (asked by users).
>=20
> Finally, you are probably noting that I'm basically stating exactly=20
> what Andreas Hochsteger suggested as a compromise.
>=20
> 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 ;-)
"

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

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

Cheers,
Reinhard

>=20
> To sum up and I've said this in the past already: it is more=20
> useful to=20
> be wrong than to be right, because you have the chance to learn=20
> something only when you are wrong.
>=20
> But there is more: being wrong is something that you might know, but=20
> fail to express, for ego preservation. This prevents others to=20
> understand that you understood and learned. This prevents others from=20
> respecting you more as a human being.
>=20
> So, let me state it clearly: I think I understood that my=20
> balkanization=20
> concerns were overemphasized and that cocoon to be able to=20
> allow other=20
> people to continue R&D in the flow control area without being limited=20
> by the current implementation.
>=20
> On the other hand, I do believe that this R&D should lead to a better=20
> single implementation rather than to a series of parallel competing=20
> implementations.
>=20
>  From the past threads, I believe the above two points sum up=20
> a general=20
> community consensus.
>=20
> I will continue the discussion based on technical comments on the=20
> original Sylvain's thread.
>=20
> --
> Stefano.
>=20