Re: goad status

[bob cs csoft net]

On Fri, 10 Sep 1999, Miguel de Icaza wrote:

> 
> > Hmm. How  about 3 checks.
> > 1. check for the NAMESERVER variable (transered by telnet)
> > 2. check for the DISPLAY and try to get the ior from X
> > 3. check ~/.nameserver.ior
> 
> (1) looks good.  (2) looks good, but we run into the distributed
> problems mentioned earlier.
> 
> (3) is bad.  because most NFS setups would end up sharing your home
> account across machines.  You really want to make the file-system
> based approach use a local file, something like
> /tmp/orbit-$user/name-server-ior.

Ok. Revised list.

Orbit resolve initial references for the nameserver should 
1. check the NAMESERVER variable for an IOR (Or maby a file that contains
an IOR?)
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.
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)
4. Try to spawn it.

As to goad, we can make it a corba object that binds to the nameserver.
That way, you could have goad runing on a master server somewhere (other
then your main computer) that could maintain the corba objects.
Distributed programming. :) ( a good example would be a webpage with
embeded corba objects. a project I am working on. The page parser and
webserver cound be on one server, and the corba objects could be on
another. )

redefining goad should break binary compatibility just a bit. 
Maby the best thing to do would be to seperate goad from libgnorba after
the 1.0.50 release. The orbit stuff should be able to be done safely now.
after the orbit fixup, I think goad should be x indemendent
right away (correct?).



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