avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] structural evolution
Date Wed, 24 Sep 2003 11:42:56 GMT
On Wednesday 24 September 2003 19:16, Stephen McConnell wrote:

<snip what="ascii art" />

> Scenario - forget about "locate, install, customize, deploy" - instead
> think about register once, and execute.  For example, if I have a
> composite component that requires a product install, instead of dragging
> in a default configuration, I want to drag in a customized configuration
> matching my profile and environment and I want it to work with zero (or
> at least near zero) intervention.  That logic resides in the "agency".
> It uses information about me, my domain, resources, etc. (stored in a
> registry) to dynamically construct a solution based on deployment
> information and artifacts available across a set of repositories.

I don't fully follow your logic.

Component maker NH creates component NSC which it places in a repository 
somewhere. NSC is composed by all kind of resources, Avalon components and 
other "stuff", which resides on their own repositories.

NH puts on hat "Agency Logic Creator" and tries to figure out what kind of 
particular configuration a particular user of NSC wants, by matching the 
"user preferences" (whatever that is) with known configuration points in NSC 
and the components/resources it uses.

Am I with you that far?

If so,
1. Whatever "user preferences" you can dream up, they are probably not needed 
by the component.
2. Since every component/resource evolves independently, it will be near 
impossible to track the needed changes from version to version. Especially, 
if the Agency program allow a block to depend on a particular older version.

I only see problems, and gut-feeling say "wrong direction". Concentrate on 
creating better component standards. As I have said in the passed, I don't 
feel we have components in Avalon yet. They are far too loose and not 
complete imho. Also, for the Agency concept to work, I think you will need 
stronger component contracts.

a. Components to encompass not only JAR material, but docs, binaries, GUI 
parts, Admin parts, whatever. Here is where I am concentrating my efforts at 
the moment.

b. Components today are "runtime only". A component in my world have a 
"non-runtime" interface(s) as well, possibly in code, so that tools and 
containers can "talk" to them in a passive mode. This is today handled by XML 
files, but that is probably too limited. Why shouldn't a component have a 
behaviour outside the container?

My 0.02 ringgit worth...


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

View raw message