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... Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
