cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Removing some of the irons from the fire [was Re: [Design] ContainerManager is under fire--let's find the best resolution]
Date Sat, 08 Jun 2002 13:24:28 GMT
People,

the idea I had of Avalon kept with my hopes: it is a meme, an infective
programming notion that sticks in your head and that can't be further
removed.

Luckily, it also moved from a meme to code than to a community effort: I
can't say I'm entirely happy with what happens over at Avalon-land, but
I love the fact that the effort is moving along (rumors say that Turbine
might get to use Avalon in the future, this is a great thing for
everybody, IMO)

You guys are working on Avalon 5, great, I want to be part of this. I'm
resubscribing to avalon-dev right now.

But some of you (all?) are cocoon lovers and you see many things that
Cocoon might do in better ways. I can't disagree, but this is making too
many irons in the fire. The fire is cooling down and I bet not many
people followed the somewhat harsh discussion between Berin, Vadim and
Leo. I couldn't myself, there was too lack of focus for my personal
taste.

The things that were put on the table (all at once) were:

 1) removing ComponentSelector
 2) removing the release() method
 3) change the behavior of the core cocoon internals

I guess that's a little too much to discuss in a single thread, don't
you think?

So, while the first 2 points don't belong to this list (no matter how
much Cocoon is tied to avalon), only the third does. But I will be
*STRONGLY* against changing any deep structure before Cocoon stabilizes
from a usability point of view.

While I understand the concepts that Berin proposes, I think they are
something for Cocoon 3. There are *much* more important things to do on
Cocoon (docs, the flowmap integration, blocks) before even trying to fix
deep architectural imperfections (which are yet to be demostrated,
anyhow)

SoC, damn it.

So, let's move the discussion on Avalon 5 in avalon-dev and when that
effort is done, we'll move it over to cocoon-dev and discuss a possible
Cocoon 3.0 internal branch... but with three/four books coming out, it
would be a *SUICIDE* even to start talking about changing those
interfaces right now, no matter how elegant the new framework will be.

In case you didn't know, there are companies outthere who are using
Cocoon or evaluating cocoon for their commercial use and investing
millions of dollars on our architectural solidity. 

This doesn't mean that we can't improve, but we must be *very* concerned
about the timing, the reasons and the intentions.

Hope this is clear to everybody.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message