Re: persistant iors

[NotZed <zucchi zedzone mmc com au>]

Hmm, or another possibility(?)  Visibroker uses a server called an 'OSAgent',
which provides name services etc.  Every server part of the application needs
to know where it is, and uses a hostname/port parameter (env var?) to
locate it.  Then they can register their objects, and clients can
look them up.

Now I dont know if it just uses another protocol to get the initial IOR,
or some sort of psuedo method invocation or something, but a simple
hostname/port is easy to setup manually if need be (the same way
DISPLAY sometimes needs to be setup manually).  I can check the
technical manuals at work if it seems worth it.

> 
> is there a way to create a corba object that has the same ior every time
> it is run on the same machine and same user?
> 
> On Sun, 12 Sep 1999 bob@cs.csoft.net wrote:
> 
> > 
> > 
> > ---------- Forwarded message ----------
> > Date: Sun, 12 Sep 1999 15:50:24 -0500 (CDT)
> > From: bob@cs.csoft.net
> > To: Yo 'Ric Dude <ricdude@toad.net>
> > Subject: Re: goad status
> > 
> > 
> > 
> > On Sun, 12 Sep 1999, Yo 'Ric Dude wrote:
> > 
> > > 
> > > How does the Interoperable Naming Service spec recommend 
> > > the "discovery" of The Name Service?  Perhaps a broadcast
> > > query to the network at large?
> > > 
> > 
> > I dont know, cant find the spec. Can you point me to it?
> > AHHH! a broadcast would be very bad. Big security problem.
> > 
> > As to your idea about persistant objects. Is there a way to do it?
> > If there is, I might have a solution figured out that would allow goad to
> > be able to work in a distributed environment and spawn objects on remote
> > servers. :)
> > 
> > > bob@cs.csoft.net wrote:
> > > > 
> > > > Ok, so revised again:
> > > > 
> > > > resolve_initial_references for nameserver
> > > > 
> > > 
> > > 0. check the command line for --orb-name-server=IOR ?
> > > 
> > > > 1. checks the environmental variable NAMESERVER
> > > 
> > > > 2. checks /tmp/orbit-$user/name-server-ior
> > > 
> > > > 3. if DISPLAY is set, load dynamic library that tries to get the IOR from
> > > 
> > > > X. (If module does not exist, ignore step 3)
> > > 
> > > 3.5  multicast/broadcast query ?
> > > 
> > > > 4. tries to spawn the name server.
> > > 
> > > > At any step in the process, if it gets an ior, it should try to contact
> > > > the name server. If it can't, it goes to the next step.
> > > 
> > > (random train of thought follows, ignore as necessary)
> > > 
> > > My initial thought is that the "root" naming context 
> > > should be independent of an X session, and should be
> > > run as a system service, preferably on a well-known
> > > port, with a persistent ior.  If it goes down, and 
> > > comes back up (respawned by inittab?), it'll be at 
> > > the same IOR.  A machine/user specific subcontext 
> > > could be used for a session's important server 
> > > locations (mail handler, web browser, etc):
> > > 
> > > 	/ - (respawns from inittab)
> > > 	/machine - per machine context
> > > 	/machine/user - machine per user session context
> > > 	/machine/user/mailhandler - bound to IOR of user's
> > > 			preferred mail handler program.
> > > 	/machine/user/webbrowser - bound to IOR of user's
> > > 			preferred web browser.
> > > 
> > > Servers run in the context of a gnome session are 
> > > kind of tied to the X environment, anyway.  Perhaps
> > > the SESSION_MANAGER variable could be used to navigate
> > > to the proper personal naming context (from the root 
> > > naming context) to find the correct iors?
> > > 
> > > -- ebm
> > > +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
> > > |  __                         a.k.a. Eric B. Mitchell |
> > > |  |_) .  _  _|      _|  _        ricdude@toad.net    |
> > > |  | \ ( (_ (_| (_| (_| (/_    www.toad.net/~ricdude  |
> > > | How's My Programming?   Call:  1 - 800 - DEV - NULL |
> > > +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
> > > 
> > 
> > 
> > 
> > -- 
> > To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> > as the Subject.
> > 
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>