persistant iors
- From: bob cs csoft net
- To: gnome-devel-list gnome org
- Subject: persistant iors
- Date: Sun, 12 Sep 1999 16:30:32 -0500 (CDT)
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]