Re: persistant iors

[bob cs csoft net]

On that note, what about a name server server.
TCPIP based. Running as daemon.
You connect to it, enter a username and password, and it fetches (and maby
starts) the nameserver running under the specified username.
Then you can use an environment variable similar to DISPLAY. 
The environment variable will not have to change, so you can safely put it
in your bashrc file (or whatever). Telnet will be able to proxy it over
similar to DISPLAY (or you can manually set it. Or put it in your remote
bashrc) 

We can make orbit use this method with resolve_initial_references on the
nameserver.

And for other orbs, create a c library that does the same thing. maby just
make a gnome_get_nameserver() or something.

On Mon, 13 Sep 1999, NotZed wrote:

> 
> 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.
> > 
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>