avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Aaron Farr <fa...@apache.org>
Subject Re: [RT] A Bright (and Radical) Future for Avalon
Date Sat, 17 Jan 2004 22:05:12 GMT
On Sat, 2004-01-17 at 16:46, Niclas Hedhman wrote:
> On Saturday 17 January 2004 13:10, J Aaron Farr wrote:
> > Definitely a Random Thought:
> > http://www.jadetower.org/muses/archives/000019.html
> > Feedback is welcome.
> I enjoyed reading it, as it reflects a fair bit of my own thoughts;
> 1. There are MANY aspects of framework construction.
> 2. There could potentially be ANY number of container implementations.
> 3. All container variations should not be part of our ambition, just like all 
> components should not be part of our ambition.
> Although I like Merlin very much, as it is in-line with my current thought 
> process, I realize that not everyone find it as amazing as I do.
> As in the article, I don't know if Merlin will be capable to be "cut up" in 
> smaller pieces that can be assembled in arbitrary constellations to suit 
> different needs. It would be great.
> But I DO believe that Avalon Framework needs some form of Playground 
> Container, where new ideas can be tested, and I DO believe that we need a 
> collection of "high quality", "low level" Reference Components, serving both 
> the need of functionality as well as education (easy to forget).

Education is easy to forget about.  One thing that has been suggested
form time to time is an Avalon super-distribution or set of
super-distos.  Something that really shows off Avalon and one or more
containers and has a bunch of components already wired and ready to go. 
Sort of an Avalon Application Server.

> Reagrding the evolution fo Avalon Framework itself, and the identification 
> that Dependency is very different from LifeCycle is a much harder nut to 
> crack. I would like to throw in a 3rd, almost forgotten, same-level issue; 
> Service Availability. And then of course, Meta-info about the components.

Yep.  But the important thing is to maintain separation of concerns. 
Lifecycles are separate from Service Dependency. Service Discovery and
Availability are probably close enough to be solved in a single
framework, but Service Dependency is probably a separate issue from
these.  Meta data (or Service Description) is a seperate issue too.

 jaaron  <http://jadetower.org>

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

View raw message