persistant iors



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]