avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Component <> Object (and never will be).
Date Tue, 12 Feb 2002 21:00:10 GMT

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, 11 February, 2002 20:03
> To: Avalon Developers List
> Subject: Re: Component <> Object (and never will be).
> Paul Hammant wrote:
> > Folks,
> >
> > Berin is putting up a good fight against the changes (as we present
> > them) being talked about.  Being proposed is JNDI as an alternative.
> > <footnote>One reason I started EOB was because I wanted a one line
> > CompMgr style lookup for *anything* and dislike the wieght of JNDI in
> > its usage</footnote>.  Reading Berin's opinion it seems that
> > ComponentManager is still the preferred tool for Components and that if
> > there is something else needed, it is for non-components.
> >
> > Perhaps this is true, and there is no overlap. Perhaps a completely
> > fresh (not clone) package is required for non-components.  It could
> > serve the needs of Object lookup and be reusable or reimplementable by
> > Stephen's CORBA work in Cornerstone, EOB (sourceforge) and
> Peter's needs.
> >
> > We could roll in some naming contexts.  I.e. "jndi:",  "phoenix:",
> > <insert Stephen's needs> <insert Peter's needs>
> My main points have always been that we shouldn't be too hasty
> just because we have a possible solution (out of many).

I'm didn't want to go down the path of exploring possible solution. I'll
restate this again - SM is a very minor generalisation of CM. It isn't
introducing any new concepts.  In fact the model of CM suits that
application cases I'm concerning with - its the implementation restriction
concerning the Component interface usage which is being addressed.

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

This has nothing to do with things like the CORBA Naming Service (INS). I'm
concerned about component management used in building applications that deal
with objects beyond the Avalon enclave.  INS is way-out-of-scope relative
to CM/SM discussions.

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

The rosolver interfaces are much heavier the CM/SM approaches.  That
not the level of complexity I'm looking for.  CM provides almost exactly
what I want - except when my components cannot implement the Component
interface (in which case SM addresses my needs completely).  I need
anything more complex than CM/SM.

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

Berin - can you outline what you think are the deficiencies you have
with CM/SM.

Cheers, Steve.

> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message