goad: how i think it should work and a patch

[Michael Lausch <mla gams co at>]

I tried to use the goad system for CORBA servers. In order to make it
run i had to apply the following patch to
..../gnome-libs/libgnorba/goad.c. This patch is only valid, if my
assumptions and understanding of the GOAD system and semantics, which
i appended to the patch, are true.

Perhaps i'm talking complete nonsense here, but it's a start of a
description how things work and corrections are appreciated.

goad.c.patch

goad uses global and private (user specific) configuration files to
find the servers for a CORBA service. The global configuration files
are placed in the ...../etc/CORBA/servers directory (it's
/usr/local/gnome-cvs/etc/CORBA on my system), usually one per
server. The private configuration file is the ~/.gnome/CORBA/servers
file. I think the approach to have multiple global configuration files 
is to ease server installation. During installation you don't have to
parse the global config file. Just place the seerver specific config
file in the ..../etc/CORBA/servers dir.

The configuration files consists of one section per server. Take the
echo-server as an exmaple, there might be a
.../etc/CORBA/servers/echo-server 
file with the following entries

[echo-server]
type=exe
repo_id=echo-server
description=echo server for testing
location_info=/usr/local/gnome-cvs/bin/echo-server

This defines the server with the repo_id "echo-server". The repo_id
is used with the goad_server_activate_with_repo_id function for
activating a server, if it's repo_id is known.

The above mentioned echo-server can then be started with a call to
goad_server_activate_with_repo_id(0, "echo-server", \
          GOAD_ACTIVATE_REMOTE | GOAD_ACTIVATE_NEW_ONLY);
and the objref to this server is returned.

What does the flags mean?

GOAD_ACTIVATE_REMOTE gives the server activation function a hint that
a standalone executable should be started for this server
functionality. I assume that if this isn't possible, a server with the 
same repo_id, but with `type=shlib' will be used.

GOAD_ACTIVATE_SHLIB loads the server, which must be a shared library,
into the calling process. This has the effect of saving comm bandwith
and is good for low latency. Of course this only works if the server
is available for your CPU and processor and as a shared library. Also
such servers don't get registered with the CosNamingServer and it
implies much of the functionality of the GOAD_ACTIVATE_NEW_ONLY flag. 

GOAD_ACTIVATE_NEW_ONLY means that for every activation request a new
server is started. This has the side effect, that the server does not
register with the CosNamingServer. So keep care of the object ref you
get back from this call. You can't refetch it from the
CosNamingServer. If this flag isn't set, GOAD may aske the
CosNamingServer if a server with the same repo_id is already
registered and use this server instead.

GOAD_ACTIVATE_NO_NS_REGISTER doesn't register the server with the
CosNamingServer, event if it's a executable server and the
GOAD_ACTIVATE_NEW_ONLY is not given. I assume this flag is here to
help testing new servers or if you have other means to find an already 
running server (the panel uses a "proprietory" way os passing it's IOR 
string to the applets.

At last one example of a shlib type server.
[my-server]
type=shlib
repo_id=my_server1
description=my own server for shlib activation
location_info=/disk/gnome/testing-area/my-server-1/lib/libmyserver.so

In all config files more then one server can be listed. In the global
config file, the section name may not match the value of the repo_id
entry, but i think it's better to keep them the same, because in the
private config files, these two strings must match (if i read the
source correctly).