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.
