cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 15:30:34 GMT
Jorg Heymans wrote:

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

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.


View raw message