For this reason, we must identify in advance all moves that lead to making the cocoon project weaker.
There are three things that provide foundation for a project:
1) its technology 2) its community 3) its license
The three things are not so unrelated as some people think, but this is not the topic for today.
Gump indicates that Cocoon has 205 dependencies on external projects. Gump has been able to do a clean cocoon run only *once* in its entire three-years-long existance.
This is not good. It shows that we are building on sand.
There are two ways to get out of this:
1) better modularity (to reduce dependencies)
2) more solid dependencies for our core (to increase solidity of our foundations)
As for better modularity, we designed the Cocoon Blocks.
We now have to finish #2.
- 0 -
I've been helping Pier write a block-like container for his employer and found out that no matter how hard we try, the Avalon interfaces cannot allow to implement Cocoon Blocks the way we designed them.
In short: if we want to have hot-deployable, polymorphically dependent high-level cocoon web application components, we can't use Avalon4.
- o -
This leads to a rather difficult choice:
1) avoid implementing real blocks 2) change our foundation framework
I would go for #2, since I consider real blocks vital for the evolution of this project.
Now, if we go #2 there are three choices:
1) patch avalon 2) change framework 3) do our own
Here my choice would not be technologically driven but rather socially driven: I would do our own.
Why? because Avalon's communities are not healthy. The turnover rate is incredily high and the burn-out period is amazingly short. Its simply too fragile to build cocoon on something like this.
From a community perspective, Avalon is sand. Avalon's biggest problem is that technology is more important than the community. Purity that leads to forks is more important than compromises that keep the community together.
This is such a strong cultural clash which impact was for long underestimated.
Not so anymore and since now we need to make a choice, my choice would be to design our own framework and container.
- o -
So, here is my detailed proposal:
1) implement our own framework and container in order to implement cocoon blocks [this creates the solid foundation that we control]
2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs]
3) operate as incrementally as possible and work to change as little code as possible [this makes the community transition smoother, reduces enthropy and bugs introduced by the new code]
4) keep the framework and container *MINIMAL* to our own needs. [we WILL NOT redistribute the framework independently]
5) the name for our framework+container will be simply Cocoon Core
6) I volunteer to help directly in writing code
- 0 -
Now, before everybody and their dog replies to this and wishes to convince us to use their framework, the only measure of judgement would nto be technological but community and its culture.
Cocoon needs a rock solid core.
Solid in both technical, social and legal way.
I believe that social and legal solidity build technical one. The opposite is not true. Cocoon and Avalon (both highly considered from a technical perspective) demonstrate this pretty well.
I see no potential cocoon core out there that is not a one-man show and that allows us to do what we want to achieve with real blocks.
Thus the proposal to write and maintain our own, in order to finally, once and for all, build on stone and escape the social quicksands in core depenendies.
Fire at will: I have my abstesto underwear on.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
