good to see the "old" Berin back. You make sure you keep getting that sleep, bro' =)
After all those tries at summaries, this is finally one I can agree with. Now let us hope 'tis all done by the time you get back from that vacation.... cheers, - Leo On Mon, 2002-06-24 at 18:35, 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
