What you're are talking about is container internals, am I right? My outline is much more abstract (probably too abstract). Probably the best way for us to figure out what we can make "plug and play" is to begin implementing with plug-and-play functionality in mind, and then pull out interfaces as we go. You would know a lot more about this that me. I have never even played with Merlin, Fortress, etc.
However, I want to be careful not to make things too concrete. Implementation should be easy, but should be able to be done more than one way :) ----- Original Message ----- From: "Berin Loritsch" <[EMAIL PROTECTED]> To: "Avalon Developers List" <[EMAIL PROTECTED]> Sent: Thursday, November 20, 2003 11:21 AM Subject: Re: [proposal] Avalon Container Framework > Jonathan Hawkes wrote: > > > This is a follow up to the threads: [RT] IoC Type Who Cares? [proposal] IoC > > type 3.14 extension to the Avalon Framework > > > > If you are coming into this discussion late in the game, you may want to > > review the above threads for more detail. > > > > > > <snip type="implementation stuff"/> > > There are some pieces that are missing from your overview. > > The thing is that the container needs to know where it can find things. In > order to do that, we have to specify how to resolve things within the kernel. > > Meta data is very important, and all containers rely on it. Some containers > rely on *implicit* meta data by defining the values for certain aspects of > the system. Other containers are more flexible and let the user define the > meta data. The critical thing here is not so much whether to have it, but > how to access it. > > For instance, merlin has one meta model, that is fairly robust--but also very > well defined. Fortress and ECM are examples where much of the metadata is > implied or assumed. > > As long as we have a consistent interface to get metadata for a particular > class, I really don't care how it is implemented. This will allow us some > flexibility in testing or pursuing new ways to store metadata. It is the > mini-container (the small component container that you were outlining) that > needs to know how to resolve the information. > > The second important issue is how to resolve other components. As long as > we have a service type, we should be able to resolve based on what > implementations we have. The "big" container (or kernel) will take care of > the best-match algorithm, even if that best match algorithm is based on an > assembly file. > > Lastly is the subject of component configuration and container constants. > For this, the best approach I can think of is sort of a "registry" of sorts. > We need a way of automatically matching a configuration element to a particular > component, but once that is solved, the "big" container can take care of getting > all the components set up. > > I suppose another point to concider is instrumenting the components. For > example, if I want to know how long it takes to perform certain functions > on average, the container should be able to automatically add instrumentation > points on any publically accessible item. Or even insterceptors on the method > calls. > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
