avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Tue, 11 Jun 2002 10:06:11 GMT

Leo Simons wrote:
>>>>>2) removal of release()
>>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)".

Ah, now I get it. :-D

>>>>>3) replacement of Component with Object
>>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 
> we cannot (in a way expressed in java code). Is there a need?

Definately, IMNSHO.
I've seen many users start Avalon Components with new, and wait to see
the Avalon interface methods called :-O

If the component isn't created in a container, it woud be cool if it 
could barf.

<attention mode="heretic">
Component interface as a teg interface is useless and in some cases bad 
for reasons already expressed.
But maybe we could make an abstrace SafeService that can act as a base 
class to extend to make a Service that can be created only by a 
Container: private method, creator method and check of proper order of 
interface calling.

>>>>>4) replacement of ComponentException with exists() for lookup()
>>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
>>> 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).

I'm not so sure.
What do the Connection and SSLConnection components do?
Make a connection.
They use the same interfaces.

I should be able to say that I just need to make a connection or that I 
need to make a *certain* type of connection.

If we say that SSLConnection is a role itself, it will not be given me.

The fact is that sometimes I want the container to decide for me, 
sometimes I don't.
When the container decides, I just specify a role.
When I decide, I also specify a sub-role.

>>Well, this shows that hints are really not needed.
> yup. Except we have to take into account an already existing CS.

That use a hint as a sub-role usually.

>>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".

This is an implementation detail.
Or you do Role,SubRole or "role/subrole".
It's not a problem, but semantically there is a point in defining role 
and subrole.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message