Re: goad status

[bob cs csoft net]

On Sat, 11 Sep 1999, Miguel de Icaza wrote:

> 
> > 1. check the NAMESERVER variable for an IOR (Or maby a file that contains
> > an IOR?)
> 
> I would just stick the IOR there.
> 
> > 2. check X as a fallback because NAMESERVER might not transfer. It is
> > still ok because if you start a nameserver on the remote machine, it
> > will use that due to the environment variable being read first.
> 
> I want to kill this, or at least make it one of the last options and
> probably do it in a shared library module (to avoid linking at all
> with -lX11).
> 
> > 3. Fall back on /tmp/orbit-$user/name-server-ior. This will allow a user
> > to place a remote IOR by hand in it (if so inclined)
> 
> No.  This file should be setup by the name server itself.  It should
> write the IOR there atomically.  This is the well-known location for
> all servers on the system for the user.
> 
> It is important to make this the 2nd option, as we want daemons
> running on behalf of the user to be launched on demand (pilot sync
> daemons and conduits as well as the web-based mail and calendar
> services using our corba servers).

Ok, so revised again:

resolve_initial_references for nameserver

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

> 
> Miguel.
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>