+1
Berin Loritsch wrote:
> 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]>
>
>
>
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
