avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Avalon.NET container (was Re: [RRT] Getting back to the basics (long))
Date Thu, 31 Jul 2003 16:15:21 GMT
hammett wrote:

> ----- Original Message -----
> From: "Geer, Christopher S" <christopher.s.geer@lmco.com>
> 
> 
>>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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message