I think we are all focused on COP, or Component Oriented Design, here in
Avalon land. We all have the same general concepts of component
architecture: namely the relationship between container, component, and
client.
We are aware that a client can be another component, or third party
code.
Believe it or not, I also think we have been slowly converging on one
view of component resolution that provides the most power for the least
cost.
Regardless of what the origional charter of Avalon was, it has evolved
into a component architecture. This is an important thing to understand
as it has implications on the type of design that we as a group do.
Having let the smoke clear over the weekend, and now that I am fresh
(I got some much needed rest), I see some points where we really have
the same POV (for the most part). That is with component resolution
is best done the way that Stephen and Peter have been explaining it
(Looks like the S&P index is rising ;P ). That is with meta-data
associated with the class--but not by marker interfaces.
The truth is that marker interfaces are the wrong tool for the job.
What the meta-data resolution allows is for the container to finally
have a pretty unified component resolution contract. The addition
of attributes add an additional benefit of constraining the resolution
in a better way.
The unfortunate thing is that such an approach isn't well matched
for soft-binding or dynamic environments. However when you look at
how often those environments change, it is basically rearranging only
a subset of the components every time a descriptor is updated. That
update is in practice not common unless we are developing. The best
solution for soft-binding of components to lookup values is to make
it a container specific thing.
Component systems like Cocoon and my InfoMover project that will have
soft-bindings (i.e. a descriptor like a Job descriptor or a sitemap)
will have a special app-specific container that performs the remappings
as necessary. I find that a better solution than trying to make that
a framework-wide issue.
This also affects the way the component location or lookup is performed.
The lookup is a single String based value that is used to find the
component in question. That String based value is mapped to the correct
interface by the met-data. Using this approach, a component that needs
a DataSourceComponent can look it up like this: "db", and the container
will know which interface we are looking for. The lookup values are
specific to the component.
I think this vision is a good one. Most of the people on the list
seem to think so as well. Instead of quibbling over the details
we need to get the stuff to work. When we have the working prototype,
Merlin, we can see how and where it might need to be improved. Also
We can see how difficult it is to merge in with Fortress.
I have a feeling the merge is not going to be difficult at all. Marcus
has a new way of implementing extended lifecycle management which will
allow an Avalon container to directly support other types of components,
or allow any Avalon container to support application specific
extensions.
When we get that integrated into Fortress, we will look into what needs
to be improved. Again, we will look into the integration issues and
have
the functionality work for Merlin.
In the end, the merging will most likely be in the ContainerKit package.
But while we are prototyping, we should use the two main container
projects we are already developing.
Let's focus on making Avalon more obviously COP, as that is the
direction
we are taking.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
