avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Future Direction for Avalon
Date Mon, 05 May 2003 23:52:26 GMT
Stephen McConnell wrote:
> Berin Loritsch wrote:
>> Leo Simons wrote:
>>> Berin Loritsch wrote:
>>>>>    b) Cornerstone components become individual excalibur components
>>>>>       instead of one large JAR.
>>> excalibur components? Does this imply s/cornerstone/excalibur/? I'm 
>>> fine with that, but this might hurt some cornerstone users. 
>>> Specifically thinking of james.
>> Not necessarily.  Just using Excalibur as the place to store/host them. 
> Is excalibur the right place?
> Today Excalibur is largely utilities. Cornerstone is exclusively 
> components.  Take as an example the Cornerstone Threads package - it 
> provides a thread pool - it used excalibur thread as the 
> implementation.  There are very different level of abstraction that 
> exist in cornerstone versus excalibur - personally -  I prefer the 
> Excalibur == utility implementations and Cornerstone == component delivery.

And that needs to change.  Right now we have two repositories for
roughly the same thing.  I prefer not having nine different

>>> There are other things on the table not answered:
>>> 6) where is phoenix going?
>>> 7) where is fortress going?
>> As to Phoenix/Fortress they are released (or almost released).  We
>> continue to support them, and satisfy user requests for them.
> But where are Phoenix and Fortess going? It remains an open question.

Why is that still open?  They aren't going anywhere--esp. until we
have a better solution.

>>> 8) where is merlin going?
>> That is up to all of us.  Do we all want to support it?  If so, we need
>> to dive into the code to understand it.  We also need to see what
>> features it is missing and where it diverges from the standards we have
>> been trying to come to agreement for.  Once we have those issues
>> taken care of we can release it.
>> The all important question is if we as a community can support the
>> demand of three containers + the new one we are developing.
> There is already a significant level of interest in the Merlin solution 
> to the containment problem.  Simply looking at the information I have, 
> there are at least four organizations that have already engaged in 
> Merlin as the delivery vehicle for application solutions.  An 
> interesting observation here is that only one is actually using Merlin 
> APIs. This is a really important point - the entire Merlin architecture 
> and implementation has focussed on the absolute requirement to separate 
> containment concerns from component implementation concerns. This makes 
> Merlin the safest bet of any Avalon container - it simply is focussed on 
> ensuring zero API usage - maximum portability and maximum utility.

Umm, That's great, but are they willing to support it?

> More importantly - I think that the issue here is about the containment 
> architecture - not the container.  With an Avalon containment 
> architecture in place the question of "which container" becomes 
> irrelevant - your code against a containment API - not a particular 
> container.  That is the success story.

We aren't there yet.  The question still remains, is the Avalon
developer community needs to be on board to support it.  If we can't
get sufficient participation to support it.

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

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

View raw message