Leo Simons wrote:
>>>>>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)".
Ah, now I get it. :-D
>>>>>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?
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.
</attention>
>>>>>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.
Yes.
>>>>>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).
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 [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]>
