You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/07/15 17:48:01 UTC
[RT] the value of being wrong
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)
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.
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
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.
Re: [RT] the value of being wrong
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> I have taken a step back and reconsidered the whole discussion about
> flow and how to implement it.
<snip/>
Stefano,
I will not answer in detail to this RT (computer time is scarce during
holidays), but let me say that I'm happy to see your "balkanization
paranoia" going down. As you say, this community has something special,
and I think it has already proven several times its health. The recent
XMLForm story is a good example of that : a block gets "damaged" because
its main (if not only) contributor decides to leave. And we see better
reimplementations emerge (JXForm, thanks to Chris). I'm confident that
for the particular problem of flow abstractions, the community and
Darwin will do their job as usual. And if not, the few people involved
in today's discussions will take care of it ;-)
<snip/>
> 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)
To all : I am the "other people". I visited Bertrand on tuesday, and
this was not only a meeting between Cocoon people, since both families
were involved [1]. This was really great.
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/000061.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] the value of being wrong
Posted by Marc Portier <mp...@outerthought.org>.
Yo brother,
Stefano Mazzocchi wrote:
> Finally, you are probably noting that I'm basically stating exactly what
> Andreas Hochsteger suggested as a compromise.
>
actually, I rate this higher then a 'compromise' :-)
> 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.
>
thx for sharing this
I guess I missed the chance to actualy say I *do* share your care
for this community...
Still, I realize my good intentions are no guarantee, so I'ld
like to invite anyone to give me advice along the way
I'm positive that, with all of us helping out, the R&D in
different directions will not lead to realize the balkanization
fears Stefano warned us about...
warm regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [RT] the value of being wrong
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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.
>>
Re: [RT] the value of being wrong
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andreas Hochsteger wrote, On 16/07/2003 8.21:
...
> Nature and evolution has proven that many times.
> Even now we are often surprised that the behaviours and structures of
> all creatures on this earth serve a certain purpose which has been
> developed over the time.
> It was not carefully planed as a perfect world from the beginning on
> because then all creatures would have been unchanged since then.
IMHO competition is a poor substitute for collaboration.
http://www.freeroller.net/page/nicolaken/20030228#title_darwinistic_os_software_theory3
>> Cheers,
>> Reinhard
>
>
> Bye,
> Andreas Hochsteger
> http://highstick.blogspot.com/
>
> PS:
> I don't know, if I can follow this interesting discussion further, since
> I'm going to marry my girlfriend on saturday (perhaps you already noticed).
:-D Congrats!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] the value of being wrong
Posted by Niclas Hedhman <ni...@hedhman.org>.
Andreas wrote;
> Nature and evolution has proven that many times.
> Even now we are often surprised that the behaviours and structures of
> all creatures on this earth serve a certain purpose which has been
> developed over the time.
> It was not carefully planed as a perfect world from the beginning on
> because then all creatures would have been unchanged since then.
And >99% of all spieces has died off over the years.
OT:
Very interesting series running on Discovery (at least in Asia) right now,
"The Future is Wild", which discusses evolution from now into the future
(where humans "left the planet due to nature's violence").
Funny to see how scientist speculate.
"Last Mammal (100million years) a small squirell like creature, bred/fed
by spider colonies for food."
"No birds - Flying fish takes to sky."
"Squid descendents on land."
"Slime like life - advanced virus type using others DNA."
And even wilder speculations.
Re: [RT] the value of being wrong
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
> I don't know, if I can follow this interesting discussion further, since
> I'm going to marry my girlfriend on saturday (perhaps you already
> noticed). I'll be back on 29th of June.
Hi:
Hey?! Almost a year in the honeymoon that sounds great for you!
lol.
Best Regards,
Antonio Gallardo.
Re: [RT] the value of being wrong
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
> Or, if you want to rephrase,
... the communitytator?
J.Pietschmann
Re: [RT] the value of being wrong
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Jul 16, 2003, at 01:21 America/Guayaquil, Andreas
Hochsteger wrote:
> Often I thought that he's a bit arrogant (forgive me, Stefano ;-)
Arrogant? who, me?
You are *definately* and *utterly* wrong.
I'm not arrogant: I'm a stinking pain in your ass.
Or, if you want to rephrase, a bastard community slut from hell.
ehehe <grin mode="evil look"/> ;->
--
Stefano.
Re: [RT] the value of being wrong
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Reinhard Pötz wrote:
> 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 ...
I must confess, that I thought exactly the same way.
I never was feeling so much "at home" at a developer community like in
this one, even if I'm more a listener than a speaker here.
Stefano does really a great job at community management, and it takes
time for new people to realize that.
Often I thought that he's a bit arrogant (forgive me, Stefano ;-), but
now I realized, that sometimes he's provocating something (which
sometimes might be his real opinion) just to keep the community healthy.
Now I realized that it's all about the community that counts.
Excellent technical design might come by itself.
I might go even a step further:
If there's a growing community with people who respect every individual
then their product must strive to technical excellance with respect to
their real needs.
Nature and evolution has proven that many times.
Even now we are often surprised that the behaviours and structures of
all creatures on this earth serve a certain purpose which has been
developed over the time.
It was not carefully planed as a perfect world from the beginning on
because then all creatures would have been unchanged since then.
> Cheers,
> Reinhard
Bye,
Andreas Hochsteger
http://highstick.blogspot.com/
PS:
I don't know, if I can follow this interesting discussion further, since
I'm going to marry my girlfriend on saturday (perhaps you already noticed).
I'll be back on 29th of June.
RE: [RT] the value of being wrong
Posted by Reinhard Pötz <re...@gmx.net>.
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.
>