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