----- Original Message ----- From: "Geer, Christopher S" <[EMAIL PROTECTED]>
The bottom line is the container coding has already begun
Where is it?
Unless someone else has some code, the only thing that exists is a starter project with no code.
and is under way but if we go down this path of "starting over" (I know probably not the right term) then we have to first look at the framework and make sure it meets the needs for a componentized container, which I'm not sure it does right now. Right now the framework interfaces are in flux, which in turn affects the container so we need to nail down the framework before the container can really be stable.
I already say that I prefer small deliveries, small evolution of code. I thought that interfaces were already defined (at least the minimum set) and the first Avalon# container could be uploaded to CVS.
True enough. I will finalize the thoughts on the Avalon# interfaces RSN. However, that does not keep us from creating the abstraction of a ComponentFactory to allow the container to be developed and expanded even when the framework interfaces are in flux.
Something I'd like to see done is just start developing a list of capabilities that we should meet. Now I agree with Berin's XP approach concepts that say you shouldn't have "hard and fast" requirements but a living set of capabilities is a good idea so it can foster a "common goal" in the team. I still believe that we should find a way to post these to some website (that is up-to-date) as we agree on them for historical purposes unless we just continually post updated sets to the list over and over again.
Agree. This list should be done by Berin while he have the big picture.
First, let's talk a little about strategy.
Do you prefer working with a generic do all interface that can be adapted to any concern, or do you prefer to work with specific interfaces for each concern.
The RRT laid out the foundation for the very basic concerns. I used the specific approach in regards to Fortress development (separation of component factory and component lifecycle management). The two interfaces I used were the ComponentFactory and the ComponentHandler. While there is a nice distinction in responsibility and logic, the implementation leaves something to be desired. Not to mention there is no real concept of assembly which is sorely needed.
Merlin represents a different way of doing things (if I understand it correctly), in that it has a generic Appliance interface. The Appliance interface is the generic do-all interface that can be adapted many ways.
There are pros and cons of each way. I personally am more comfortable with the specific approach, because I know what to expect with each type of component. Personally, I would like to start with what I know. If the different interfaces end up with the same set of methods, we can look at generalizing them at that time.
The Avalon.NET container needs to provide the following abilities:
* The ability to create and instantiate a component. * The ability to destroy a component. * Assemble components (provide a mapping functionality).
Here are some possibilities:
ComponentFactory
{
Object Create();
}LifestyleHandler
{
Object GetInstance();
}ResourceRepository
{
Configuration GetConfigurationFor(string role);
Object GetComponentFor(string role);
Object GetResource(string urn);
}ComponentDecorator
{
Object Decorate(Object component);
}These are just scratchings, and open for discussion. I think ComponentFactory and LifestyleHandler are self explanatory. The ResourceRepository I am not convinced about yet. It's just a wild thought. The idea is that factories, handlers, and decorators all need to access a set of information. Having one interface to return a type of information might be useful. The role string might be duplicated accross components so it is really too weak a contract. Perhaps URN would work better.
The Decorator concept is not needed imediately, but this is where we would add component proxies, arbitrary functions, etc. It isn't clear if it would work for producing management objects, etc. We can leave it out until we are ready to play with it.
I am definitely open to suggestion.
--
"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]
