Re: panel error *** ORBit patch ***

[Miguel de Icaza <miguel nuclecu unam mx>]

> If programs encounter a broken runtime environment, they are not required
> to run perfectly. If the environment does not provide the basic
> necessities (which, for a network desktop, includes core network
> services), then it's reasonable to exit

Elliot, GNOME is a network-aware network desktop, that does not mean
it requires a working network setup to run:  The GNOME desktop should
come up even if the network configuration is Evi Nemeth's nightmare.

It should run with a broken network configuration: imagine a user
trying to fix his networking setup.  

> The default /etc/hosts on most systems (which would produce localhost ->
> 127.0.0.1 -> localhost.localdomain, I think) should work fine. 

This is a Red Hat-ism.  127.0.0.1 does map to localhost (stock SunOS,
stock Solaris, stock IRIX).

> The big problem with putting little hacks like this in is that we wind up
> with a "good enough" mentality similar to the one that Bill "640k will be
> enough" Gates purportedly holds. 

It is not the same Elliot.  You wont escape just because you quote
"Bill Gates":  Point stands, there is a problem for people that run on
networks where their IP might change (laptop users, diald users,
some mobile ip setups) and whose networking setup might be broken and
the changes might requiere privileged access to modify and in some
cases, lots of paperwork and lots of explanations to people which dont
care that your gnome desktop does not work.

> Yes, we could indeed hard-code "localhost" in, but that would defeat
> the whole point of having a NETWORK desktop.

Same objection: we are a network AWARE desktop.  Not a network
DEPENDANT desktop. 

> Here's the premises I'm working under:
> 	  - 'hostname' should resolve to a valid IP address, loopback or otherwise.
> 	  - The IP address pointed to by 'hostname' should reverse-resolve
> 	    to a valid hostname (presumably, but not required to be, the FQDN)
> 	  - The 'hostname' and/or FQDN retrieved using the above procedure
> 	    should be valid for the lifetime of a CORBA server (and the

This is not acceptable Elliot.  

So, that means that if my machines gets an IP address, disconnects,
and later diald reconnects, if I get a different host name, then the
integrity of the applications is not guaranteed?  

If there is no other way to fix this, then I suggest that by default
all of the GNOME CORBA exported IORs use localhost.  If the user
wants to connect his server across networks, it is up to him to
convert the IOR to an exportable IOR.

There should be one way of telling ORBit to do so. 

> Does anyone know how X handles this whole conundrum? It has the _exact_
> same problem WRT setting $DISPLAY and all. 

When you run locally, you do not have DISPLAY set to your hostname:0,
you have it set to :0.  This means: all connections on the localhost
use the special local transport communication system.

The different is very simple: with ORBit you are using the same
naming scheme for local objects and remote objects (that is what you
are including on the IOR), while on the case of X, for local
applications you use a specific name ":0" and on remote connections
you use "remotedisplay:0".

> (Part of the problem is that CORBA encodes the hostname inside the IOR
> instead of leaving it directly manipulatable like X $DISPLAY's do. Perhaps
> we just need an iiop:// URL parser instead - any volunteers? It shouldn't
> be too hard, since all ORBit object keys are strings... :-)

That still wont fix the problem.  Because you are still using the same
name (whatever you encode in the iiop://.*) for local and remote
connections.

A solution would be to provide two different IORs: one for
applications running on the local system, and one for remote
applications that wish to talk to our servers.

Miguel.