[omniORB] omniNames

Wed Jun 5 21:09:02 2002

Hi

Another analogy would be...
If I drive to work the same way each day, then when I get to the road where
my work is, then I would expect to see my workplace.
If I were to take the omnames bus, then everytime it got to my work, there
would be a different place of work there each time. (Contractors heaven
maybe).

One of my developers is using the path to the ior, but not the full path ex
/usr/local/bin and not say /usr/local/bin/bash. But he is getting the
correct pointer to the pop-mail.  I dread the day when he trys to
instantiate the mail object, and trys to send mail.

----- Original Message -----
From: "William H Jones" <enjones@lerc.nasa.gov>
To: <omniorb-list@realvnc.com>
Sent: Wednesday, June 05, 2002 6:23 PM
Subject: Re: [omniORB] omniNames

> Warren,
>
>   Having never examined the omniNames code or read the naming
> service standard...
>
>   Each naming context consists of an instance that, principally,
> contains 0 to n references to other instances.  You are provided
> methods to get at those references.  Those references can be
> either to the CORBA object you have bound to the naming context,
> or to another naming context instance, in which case you can look
> through the instance references it has.
>
>   The resolve method does this for you iteratively.  It starts
> at the root (or probably, at the instance presenting the resolve
> method), picks off the first element of the name you supply, and
> tries to identify the next CORBA instance based on that name.  If
> the identified instance is another naming context, it continues
> the process and navigates on.  Presuming that the naming contexts
> continue to match the supplied name and all other expectations are
> met, it continues on until it exhausts the supplied name.  At that
> point it stops and, apparently, gives you some reference, even if
> there is more than one to choose from.  It would appear from the
> results you've gotten that omniNames has organized references within
> a context with a hash table, rather than sorting them alphabetically,
> which is why your example comes out with pop-mail-01 instead of
> mid-mail-01.
>
>   There is actually functionality to allow you to do this traversal
> yourself rather than rely upon the resolve name-iteration process.
> This can be useful when you have other traversal strategies that
> you want to pursue.  For example, see
>
>   http://www.grc.nasa.gov/WWW/price000/pfc/htc/gfcbindginterfaceinfo.html
>
> (if I typed the URL right) where I invoke functionality to first
> traverse up the naming context tree by name as long as the names
> match, and then shift over to random selection until I get
> to the desired instance kind.  This gives me some sense of
> client/server co-locality while it lasts, and then assures that
> I continue on until I finally do get to the expected instance kind.
>
>
> Or maybe it is all completely different....
>
> Hope this helps,
>
> Bill
>
>
>
> > From omniorb-list-admin@realvnc.com Wed Jun  5 11:54 EDT 2002
> > From: "Warren Brown" <warren@scully.xfiles.za.org>
> > To: <omniorb-list@realvnc.com>
> > MIME-Version: 1.0
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> > Subject: [omniORB] omniNames
> > X-BeenThere: omniorb-list@realvnc.com
> > X-Mailman-Version: 2.0.11
> > List-Help: <mailto:omniorb-list-request@realvnc.com?subject=help>
> > List-Post: <mailto:omniorb-list@realvnc.com>
> > List-Subscribe: <http://www.realvnc.com/mailman/listinfo/omniorb-list>,
> > <mailto:omniorb-list-request@realvnc.com?subject=subscribe>
> > List-Id: The omniORB Discussion List <omniorb-list.realvnc.com>
> > List-Unsubscribe:
<http://www.realvnc.com/mailman/listinfo/omniorb-list>,
> > <mailto:omniorb-list-request@realvnc.com?subject=unsubscribe>
> > List-Archive: <http://www.realvnc.com/pipermail/omniorb-list/>
> > X-Original-Date: Wed, 5 Jun 2002 16:30:35 +0200
> > Date: Wed, 5 Jun 2002 16:30:35 +0200
> >
> > Hi
> >
> > I have two iors stored in the nameservice.
> >
> > 1) development/internal/mail/mid-mail-01
> > 2) development/internal/mail/pop-mail-01
> >
> > If I use
> > nameclt resolve development/internal/mail/mid-mail-01
> > or
> > nameclt resolve development/internal/mail/pop-mail-01
> >
> > it replies with the correct ior.
> > But if I do
> >
> > nameclt resolve development/internal/mail
> > it comes back with the pop-mail-01 ior.
> >
> > Why is this?
> > To use the directory analogy, shouldn't it return with 'Not a file" or
is our nameservice a bit buggered?
> >
> > thanks
> >
> > W. Brown
>
> --
>
> Dr. William H. Jones
> MS 5-11
> NASA Lewis Research Center
> 21000 Brookpark Road
> Cleveland, OH 44135
>
> 216 433 5862
> Preferred:  William.H.Jones@grc.nasa.gov
> Hard code:  enjones@witsend.grc.nasa.gov
> Personal:   whjones@apk.net
>
> Project Integration Architecture:
>   http://www.grc.nasa.gov/WWW/price000/index.html
>
> No man is so fortunate but that, at the hour of his doom,
> he will not have at least a few about him who are pleased
> with the proceedings.
>     -- Marcus Aurelius
> _______________________________________________
> omniORB-list mailing list
> omniORB-list@realvnc.com
> http://www.realvnc.com/mailman/listinfo/omniorb-list
>