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 Thu, 13 Jun 2002 11:33:11 GMT
Stephen McConnell wrote:
 >
 >
 > Peter Donald wrote:
 >
 >>> Attempt at enforcing the "principal" that a key corresponds to an
 >>> interface effectively negates the potential for multiple service
 >>> provision where a interface is shared by more than one provided service
 >>
 >>
 >> No it does not. Decorate it at end with a "/key" and voila multiple
 >> service provision of service with same interface.
 >

Ok, I'll try to give my opinion on this.

<note>
BTW, it seems I'm not the only one that gets frustrated ;-) on these 
discussions that are full of meaning and where it's humanly hard to 
understand what the others think. It's because we *really* want to 
understand and get the best, and this is good :-)
</note>


 > LET ME MAKE THIS REAL CLEAR,
 > I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
 > "something" in the context of a component lookup key value.

Not different.
Your phrase is correct.

The point is: what do you want to lookup?

a) a component in a named list of components
b) a component in a *hierarchy* of components

 > IF THE ANSWER IS THAT IT MUST BE DONE THAT WAY TO BE COMPATABLE WITH A
 > PARTICULAR CONTAINER THEN THIS IS PLAIN BAD, BAD, BAD - AND SHOULD BE
 > DRAGGED IN THE OPEN - REVIWED, AND DISCUSSED OPENLY.  If it is not the
 > case - then *please* explain *what* my stubborn, irrational and
 > ill-informed actions are breaking.

We could break the *hierarchy* use of the lookup.

What do I mean by hierarchical?
Basically the same thing as in OOP classes.

An example that I like is the (made up) Connection role.

CASE 1
--------
Let's say that we have a Connection role that is mapped (in some way, 
let's not get into classname-versus-id thing) to the 
org.apache.ciao.Connection.

Then we have three implementations:
org.apache.ciao.TcpConnection
org.apache.ciao.UdpConnection
org.apache.ciao.TcpSSLConnection
org.apache.ciao.UdpSSLConnection

If a component wants a Connection Component, the container can give any 
and the user is ok with it.

CASE 2
--------
Now, let's say that the Component wants to have a Connection Component 
that is secure, such as org.apache.ciao.TcpSSLConnection.

I could create the role SecureConnection, and map it to 
org.apache.ciao.SecureConnection that /extends/ Connection.
I have
org.apache.ciao.TcpSSLConnection
org.apache.ciao.UdpSSLConnection
that the container can give.

Or I could create the "subrole" Secure, and ask for a 
"Connection/Secure" Object.

                   -oOo-

Basically, it seemed natural to me and to others to specify the 
component as a role+behaviour.

role=java interface
behaviour="way" of working

Now, as you are not using interfaces as markers, I understand that you 
have a defined list of roles with the components to give to your app...

Which you cannot do in all cases.

Take Cocoon for example.
The sitemap uses and assembles Components based on their role, but 
requests them based on the behaviour (hint).

In essence, it uses Roles as generic interfaces to the Role+hint key.

***************
What single flat keys lack is the possibility of requesting different 
components that have different behaviours in different moments, while 
keeping the same role.
***************

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


Mime
View raw message