avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <anryo...@users.sourceforge.net>
Subject Re: Component <> Object (and never will be).
Date Tue, 12 Feb 2002 15:57:31 GMT
Berin Loritsch wrote:
> My main points have always been that we shouldn't be too hasty just because
> we have a possible solution (out of many).
I totally agree, especially when it comes to framework design, but I 
also think we should all be open-minded for new ideas and even 
fundamental changes to the API, if it improves the overall quality and 
usability of the framework.

> Notice that I also did not put up a fight without proposing a solution.
> It is true that Object != Component (although the reverse is true).
> 
> With an ORB, there is another naming and lookup service that is part of
> the CORBA spec--for those, it would be better to handle references through
> that.
> 
> I understand the desire, and even need for having one unified way of
> looking up object references--that is simple and elegant, and can differ
> to the heavier JNDI and ORB Naming service.
Let's take a quick look at both of these.

JNDI is an interface for naming services. It's not meant just for 
component management, but provides a convenient (and popular) way of 
handling it.

CORBA is meant primarily for managing and sharing objects (including 
components) in distributed environments.

Now, as both of these are commonly used for managing components, it 
should be made easy to integrate either one in the core Avalon component 
management.

The issue of Component vs. Object really comes down to the following 
question: should an object be required to implement an empty marker 
interface to be regarded as a component (thus making integration with 
other systems more difficult)? I think not.

> That is why I proposed the resolver interfaces, to solicit feedback on
> that.  Is this something that will satisfy everyone's need?  I think it
> will be a much better fit than even the current CM/CS approach we have
> now.
Is it intended to replace CM/CS?

> Please, I am soliciting feedback on the proposal, so we can see if it
> fits all our needs.
A few ideas...

1. Resolveable -> Resolvable (to make it more English :)

2. resolver(Resolver) -> setResolver(Resolver), to make it more 
intuitive (consider e.g. iterator()).

3. I would consider string (e.g. URI) lookups in addition to the heavier 
Query structure. Some examples:

uri://domain.com/services/UserManager

uri://domain.com/User?id=42
uri://domain.com/User[lastName=Doe,firstName=Jane]

Service:type=UserMgmt,country=FI  (JMX style)

(All of these could be represented with an object, if necessary. See 
e.g. javax.management.ObjectName)

4. In Token: Object[] references() -> Iterator references(), not to 
restrict the implementation (e.g. in case there are MANY references).

5. What are the benefits of differentiating COMPONENT, SERVICE and OBJECT?

(: A ;)
-- 
Antti Koivunen | "Anrie" [un-ree] <anryoshi@users.sf.net>
---------------------------------------------------------
Happiness isn't about having everything you want;
           it's about wanting everything you have.
---------------------------------------------------------



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