> >>> 2) removal of release() > > -1 > > Still don't understand how I can deallocate a scarse resource as soon as > possible :-/ > How the hell can I release a scarse resource right away? > If processor hardware threads would never release() and use only a > timeout, what processors would we have? :-S > > I agree that release is *not* compulsory for pooling, but I don't see > replacements possible for handling of scarse resources.
=) We remove pooling from the CM alltogether. That's "removal of release() from the CM (and putting the pool (with release() in the CM)". > >>> 3) replacement of Component with Object > >> > >> +1s > > +1 > > Why did we use _Component_ in the first place? beautification. > How can we make an Object be sure that it's being treated by an Avalon > container? we cannot (in a way expressed in java code). Is there a need? > >>> 4) replacement of ComponentException with exists() for lookup() > > -1 > > Exception throwing is a contract with the caller, that states that the > caller is responsible for the Exception. I think it most likely that the exception will just be rethrown from compose(), so it ends up with the caller again. > >>> 5) addition of an _optional_ lookup() method that supports hints, to > >>> enable smooth migration from ComponentSelector usage > >> > >> -1s > > > > From a pure framework perspective I'm totally in agreement with the > > above (irrespective of the pain and suffering I'm enduring with respect > > to the metainfo/metadata issues inflicted by an unmentionable > > "Australia" personality). However, if we take into account ECM and the > > interest in facilitating a smooth migration path, I see only two > > alternative; either we provide a lookup( role, hint) in the framework > > (which I dislike in terms of the curent form being dicusssed), or (b) an > > extended CM is defintion at the excalibur level that provide a bridge > > from ECM to the emerging container models. > > Now, this thing of /hints/ got me thinking. > > As I said previously, it seems that: > > Role: what > Hint: how ... > ROLE: what it should do > CHARACTERIZATION: how it should do it > PREFERRED ACTOR: hint about *who* should do it nope. The role determines what part a component plays in your application; it is perfectly valid for the role to include information on the "how". Tight coupling of role to interface name is merely a convenience (it allows us to get away with easy casts). > Well, this shows that hints are really not needed. yup. Except we have to take into account an already existing CS. > The point is that we need a sub-role. > An interface (Role), tells me what to do, but does not specify how it > should be done. > This is not something that can be forgotten, as in the SSL case. > > I would deprecate hints in favor of sub-roles (or call them in a better > way, I'm no ace in names ;-) strings are pretty free-form. It is easy to describe both a role "king of all England" and a sub-role "mad" in a single string: "mad king of all England". - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
