Cocoon needs a rock solid core.
Solid in both technical, social and legal way.
Stefano,
- i am considering cocoon as the basis for a new product in the next 3 months. It will be based on 2.1.x, a possible future core migration makes me nervous to say the least. My previous decision last year in may to use the 2.0.x branch for my project backfired when i now see how much easier things could have been with flow, woody etc.
eheh, well, you'll have the same perception next year, trust me ;-)
But at the same time, we will provide a legacy sandbox so that migration will be easier for you.
Cocoon strives to find a balance between innovation and compatibility. if you have a better idea on how we can achieve them, I'm all ears! Really, I'm not sarcastic, I think we all want to make cocoon better but also make our users happy and feel comfortable with its solidity.
Unfortunatley, these are two forces pointing in the opposite direction and finding a balance that doesn't tear apart the social structure of this project is hard and tricky.
I think my plan of action makes a good balance, but, again, I'm very open to alternative courses of action.
But just like flow and cforms show, it would be a shame to stop the innovative forces and wonderful creativity that this project and its community contains.
- developing the new core will draw developer resources and focus away from the 2.1.x branch - right? I know, it's OSS, so i can just jump in and fill the gaps where needed. Again makes me nervous.
Keep in mind that the new core will touch code that you have probably never seen and that you'll never touch yourself. Stuff like the very deep internals of the sitemap processor, for example, or the cache mechanism, or how sources are resolved and pipeline assembled.
You wouldn't touch those things anyway, but we are not going to touch them for 2.1 either because they are rock solid already! [besides the store leaking, but that's an issue that we'll have to solve anyway and we may back=port it from 2.1 or viceversa]
My point is: I'm not writing any code at the moment for cocoon, so is Pier, so is Sylvain, so it's Carsten.... Say we start working on 2.2 *WHILE* everybody keep fixing bugs on cforms and polishes configuration files and documentation, that does not reduce anything from 2.1
Parallelization is the key.
Today 2.1 reached the architectural limits of what a built-time modular system can do and this makes it too hard for people to fix things in the core.
And there is so much to polish in there!
So, to cut it short: 2.2 will not *DRAIN AWAY* forces from 2.1, 2.2 will unlock forces that 2.1 is already stopping!
- being able to reuse avalon components in cocoon and vice versa was a big selling point for me and made me feel comfortable in choosing cocoon as my future preferred container.
Well, dream on. Avalon components have never been reusable across containers becaus of every container being somewhat different. Also, Excalibur is going to die, either migrated to jakarta-commons or brought back in cocoon.
Sure, on paper it looks fantastic and, believe me, that was the original vision when I proposed Avalon.
But as the name say, this is a mythical place, a dream, a pulsion.
Real life shows that there is no such place and I'm now stopping from donating resources or limiting ourselves to find a place that I now believe it doesn't exist.
Maybe i should go and read your presentation on blocks to see what all the fuss is about and why cocoon absolutely can't survive without them.
Well, it took a great deal of time and effort to convince this community of the power of the sitemap first, then continuations.
I'm ready to keep pushing for real blocks this time, because I think this is the next major revolution in webapp frameworks.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
