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] <[EMAIL PROTECTED]>
---------------------------------------------------------
Happiness isn't about having everything you want;
it's about wanting everything you have.
---------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
