avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Fresh Perspective
Date Wed, 19 Jun 2002 20:09:06 GMT
> From: Stephen McConnell [mailto:mcconnell@osm.net] 
> 
> Perhaps it would be better to look at this in terms of the 
> real issues.  There are two competing value propositions.  On 
> one hand there is a community of users that are taking an 
> approach to component management with is code centric. On the 
> other-hand there is a community of users that are taking a 
> type centric approach (meta etc).  A conflict exists between 
> these two approach.  The propagation of the code centric 
> approach negates potential and value gained from the type 
> centric approach.  The propagation of a type centric approach 
> has a negative impact on the value and forward-looking 
> potential of existing code centric products. This is a 
> battle.  For the type centric community the battle is about 
> winning the hearts and minds of the existing code centric 
> community.  That battle will depend on the type community 
> demonstrating the extraordinary high value proposition on 
> offer, together with the delivery of a migration path on 
> which we can collectively move forward.  That objective is 
> achievable, deliverable and desirable.  
> 
> But what was it that Jane Fonda said .. "no pain, no gain".

:)

Stephen, Thank you for your detailed response.  Of course you
know that I have new questions :)

> >4. locator.lookup("my-component/SSL");
> 
> Some basic concepts:
> 
> Consumer Components
> 
> These are components that declare dependencies on services. 
> Remember that "service" means (a) interface, (b) version, and 
> (c) attributes. A component X may declare a dependency as follows:
> 
> <dependency name="org.apache.playground.MyComponent" 
> version="2.1"> <attributes> <attribute name="policy" 
> value="SSL_ENABLED"/> </attributes> </dependency>

Right now, I want to understand how attributes are set up.
If a component declares that it wants an ConnectionManager
with the policy set to SSL_ENABLED, the question comes as
to who sets the attribute names and what the available
options are.

For instance, how am I the poor user of a ConnectionManager
assured that the attribute "policy" means something to the
container in relation to the ConnectionManager component?
Furthermore, how am I as a developer assured that SSL_ENABLED
is the proper key and not TLS_ENABLED?

My point is that these attributes in order for them to be
meaningful and reliable have to be identified with the
Component's role interface.  There has to be a way of saying
authoritatively that "policy" is the correct attribute name,
and the available alternatives are "UDP", "UDP-TLS", "TCP",
"TCP-TLS" or something along those lines.

So far I think I got what you are saying, and it lends more
power to the container and to COP in general.  It enforces
the fact that the component supplied is the kind needed,
without using long names, selectors, etc.

The only sticking point is the definition of the attributes.


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