Re: deploying bonobo apps on nfs share directory

[Michael Meeks <michael ximian com>]

Hi Gilbert,

On Tue, 2002-11-12 at 07:23, Gilbert Fang wrote:
>   Now, I  need to deploy bonobo-based apps, for example, evolution in  a 
> nfs share directory for our company. It always failed for bonobo control 
> creation.  I read some source code of bonobo-activation and found that 
> oafd/b-a-s is actually forked by first client/servant on request.

	Yes - we have to fork it sometime it turns out ;-)

>  And it 
> seems oafd/b-a-s 's location is hardcoded in the source code -- the path 
> of the program and the oaf file path  can be configured when build, but 
> can not change in runtime,and the name of the program  and the temp ior 
> file in orbit-tmp dirctory is hardcode.

	Hmm; ok - so, certainly the IOR is hard-coded, and it's in the local
machine's /tmp directory; do you have NFS mounted temp ? if so, it's
likely you'll run into horrible locking / coherency problems with oafd
and gconfd.

	So; is the question, 'how can I move the tmp (sockets) dir to
/mnt/foo/baa/baz/tmp' ? - note that on some Unix' there is a hard limit
to the length of the socket paths we use there. Also the ORB uses that
directory not just oafd - so it's really best if there is a /tmp. Can
you not create a symlink in '/tmp' or somesuch ? In short, I'm confused
about your setup :-)

	As for hard-coding the oafd path; I believe oaf-registration.c
(oaf_ac_cmd) that we simply execute the first oafd in the path. Thus
indeed it's not possible to have 15 parallel setups, all in the path at
the same time and expect anything but the first to be exeuted.

	What are you trying to do there ?

>    So, the problem is
>       1) how can client  in a nfs share fork/active  oafd/bas  ?
>       2) how can  oafd/bas  know the oaf files in  a nfs share path?

	'bas' ? so to point at the oaf files in the nfs share; you want to
either: export GNOME_PATH=, or OAF_ACTIVATION_PATH, or setup
/etc/oaf/oaf-config.xml.

>   1) I can not make sure where to find the right oafd/bas , because we 
> use solaris and there may be several gnome in the different path.

	I think you're confused here.

>   2) If other apps such nautilus has actived the oafd and usually it 
> has,  then such enviroment exporting will be useless.

	Yes; quite right - the environment needs to be homogenous across all
the applications; it's pretty useless having a desktop that's confused
as to which components are registered.

	Finally - 'oafd' is a different daemon to bonobo-activation-server,
which is what you should be using for the Gnome 2.0 nautilus.

> Then could we add some parameters in bonobo activation api so as to 
> specify which oafd we use and ship oafd with evolution?

	That sounds like a very half-formed idea; can you specify your problem
/ setup more completely.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot