> this is my understanding of the sort-of concensus we have arrived at.
it is my understanding too. > Some issues are still being debated, and I believe I have marked those > as such. Yep. <snip summary /> some more thoughts: > Implications of Type 1 (my own thoughts, no concensus on this): > > + As there is no release() or equivalent, the implementation is > restricted to only holding resources during method invokations. +1, only by contract though, no way to enforce this > + All implementations must be thread safe. thought: in a simple singlethreaded use of the framework, thread safety is not something to be concerned about. It'd be nice to not require a lot of work in this kind of setup. Should be possible. > Implications of types 2 and 3 (my own thoughts, no concensus on this): > > + As there is a release() or equivalent, the implementation may > hold resources during the entire transaction. +1 > + Implementations may be thread safe, but need not be. +1 > + For components of this type selected with a hint, we still > get the ugly two-step lookup we have with ComponentSelectors. yup. > + A XXXXManager interface and a corresponding implementation is > needed for each type 2 and 3 component == more code to write. yup, but that code can be within avalon == all but completely transparant to component developer. Right? this is a fruitful discussion...Berin and Pete have been at it for ages; looks like there is finally some progress =) - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
