avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future Direction for Avalon
Date Tue, 06 May 2003 02:09:51 GMT
>>I view Berin's comments as saying that we learn from A4, take the best
>>learned from implementing Phoenix, Merlin, et al, focus on a clean
>>microkernel, focus on a clean "pure" Avalon container, and add
>>with existing containers.

> Just a note - focussing on pure "Avalon" is IMHO possible the wrong
> approach.

IIRC, I was quoting Berin.  However, my impression of what he meant was that
some things that are part of the contracts from existing containers might
not be considered desireable in 20/20 highsight.  Those would need to be
supported for compatibility, but not considered part of the "pure" Avalon

> What is much more interesting is delivery of the ability
> to host a component model.

If by this you mean the architecture of the micro-kernel, and how container
services interfact to create a container, I agree.

> > Good.  Hopefully [Merlin] has been a valuable learning experience
> > that can be leveraged when developing the A5 microkernel and
> > container services.

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

Agreed.  There should be a firewall between components and the underlying
infrastructure, and this allows the infrastructure to evolve without
impacting clients.

> it is unrealistic to ask the question "which container will win"

Not only unrealistic, but meaningless.  AFAICS, none of the current
implementations *are* the A5 container, each of them have things to
contribute, and none of them can "lose" in terms of their client interfaces
being abandoned.

> the good question is "which container architecture is going
> to protect my investment".

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

To whom does containment architecture matter?  Whichever of the major
containers one picks, its interfaces will be supported.  From a client
perspective, that is the end of that discussion; components intended to run
with an A4 container will be supported by the A5 container with an
appropriate set of container services.  To what extent existing container
toolkits will be supported in A5 is a separate issue.

	--- Noel

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

View raw message