avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Future Direction for Avalon
Date Tue, 06 May 2003 01:26:04 GMT

Noel J. Bergman wrote:

>>>With a SpearHead microkernel and something that does not explicitly
>>>*require* A4 we can play around and see what works.  I want A5 to
>>>focus on simplicity/simplifying A4.
>I view Berin's comments as saying that we learn from A4, take the best ideas
>learned from implementing Phoenix, Merlin, et al, focus on a clean
>microkernel, focus on a clean "pure" Avalon container, and add compatibility
>with existing containers.  The closer to the core, the more the need to
>preserve simple elegance.

Just a note - focussing on pure "Avalon" is IMHO possible the wrong 
approach.  I look at Avalon as the bootstrap component contract, 
however, there are other component contracts out there.  What is much 
more interesting is delivery of the ability to host a component model.  
While I am well aware that this view point introduced complexity - I'm 
also well aware that his viewpoint forces re-assessment of the Avalon 
component model in a completely new context.  I find that interesting 
and, ... well, fun!

>>>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.
>If the Avalon V container is based upon the micro-kernel + container
>services (some of which, to borrow a term used in other microkernel
>environments, would be "personalities") approach, what percentage of COMMON
>code do you believe would be reasonable between an A5 container configured
>with a Phoenix personality and one configured with a Merlin personality?  I
>think that subject should be addressed in a separate thread (so lets not go
>into *details* in this one), but my point for bringing it up is to suggest
>that it will be easier for the Community to sustain multiple personalities
>if there is more commonality between them.

As suggested, I'll respond to this under a separate thread!

>>the entire Merlin architecture and implementation has focussed
>>on the absolute requirement to separate containment concerns
>>from component implementation concerns.
>Good.  Hopefully that has been a valuable learning experience that can be
>leveraged when developing the A5 microkernel and container services.

Absolutely - jump into Merlin and you will see evidence of this all over 
the place.  One of the interesting things about work on the containment 
side is that you have much more liberty with respect to change.  Clients 
should not have to import container APIs - and given this mandate - the 
container should be evolve in unforeseen ways.  Looking at today's 
scenario with way too much "brand" focus, it is unrealistic to ask the 
question "which container will win" - first of all its the wrong 
question - the good question is "which container architecture is going 
to protect my investment".  Our answer to that is a lot more complicated 
- some containment architectures have more investment protection value 
than others. All containers can benefit in terms of investment 
protection delivered by leveraging a common containment services model.

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message