cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Thu, 14 Oct 2004 10:59:05 GMT
Ugo Cei wrote:
> Il giorno 13/ott/04, alle 23:23, Vadim Gritsenko ha scritto:
> 
>>  * Why new type of container is needed;
>>    (I suppose: because some things are broken)
>>  * What's broken in ECM;
> 
> Quoting Stefano:
> 
> "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."
> 
> <http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108004833707209&w=2>

I was asking about intra container (see orig email); quote above is about 
kernerl container.


>>  * Why it can't be fixed in Fortress;
> 
> 
> It might be fixed, maybe. My impression, however, is that Avalon with  
> Fortress/Merlin/Metro/Magic/Excalibur/Kingarthur/Lancelot/Guinevere/ 
> Whatever is quickly fading into irrelevance. I was subscribed to the  
> Excalibur mailing lists until a couple of days ago. There was almost  
> nothing there besides talk about hot to fix the problems with Gump. I  
> unsubscribed from Avalon even earlier.
> 
> I need a framework which provides today lots of prepackaged modules  
> helping with persistence, transactions, messaging, management (in the  
> JMX sense). In two words: enterprise services. I don't see anything  
> better than Spring it this respect.
> 
> [I just realized I promised earlier not to fall into a  
> container-religion-war type of argument, and I didn't mantain the  
> promise, but since you asked a direct question...]

Ok. Want to give a quick overview of spring features we as enterprise cocooners 
should be interested in? (and how it compares with current situation) :)


>>  * Why Avalon compatibility can't be achived with new
>>    container (so that you need second one in parallel).
> 
> 
> May be. I just thought it might have been easier that way. No  
> compatibility layer to write. if you have legacy components just run  
> them in the legacy container, which is not much more than ECM, and we  
> already have that. This is however an implementation decision and it is  
> IMHO better to start doing it one way or the other and see which one is  
> better. I'm all for agile, test-driven development, so what I would do  
> is write some tests, implement the simplest thing that might possibly  
> work and refactor.

Personally, I'd favor Avalon support for chosen container. As Ralph noted, and 
he is not alone, people like Avalon, and we should support it for years to come.

So why to run two containers - one too much - if Avalon support can be 
implemented in new container of choice. More memory, management, and confusion 
overhead. And people also would ask why two containers if old is still there and 
is used 99% of time (and that's where you answer on my question above - what's 
so cool about new container - helps).

Vadim

Mime
View raw message