Re: deploying bonobo apps on nfs share directory

[Gilbert Fang <gilbert fang sun com>]

Hi, Michael
sorry to bother you again.


Michael Meeks wrote:
>  
>   
> >  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 ?
I absolutely  do not want to mount a nfs directory  to replace the  /tmp/<orbit-socket-tmp-dir>.
We may need several parallel installation because there may be several evolution
versions. In fact, now our company has installed several netscape (two version
of ns4.7x and ns6, ns7 , etc.). 

If user has started  gnome desktop, much  possibly he has activated a local
oafd, thus we have no chance to add a nfs dirctory to oaf_activaton_path,
and generally, we do not expect all user has a superuser priviledge to change
/etc/oaf/oaf-config.xml and also do not 
expect user a linux expert to set complex env viarales and kill-restart 
appropriate process. we need to write a shell script to do it automatically.


>  
>   
> >    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.
Thanks very much. I try to modify oaf-config.xml, it works very well. 
For OAF_ACTIVATION_PATH, does this env variable just infect oafd, and bonobo
related apps?  
And I think the variable can only be effecive  if I export it to one of my
bonobo apps before oafd has been  avtivated 
for the first time.

By the way,  I wonder whether GNOME_PATH  will influnce all the gnome-apps
or only bonobo-apps and oafd ?
I donot want a whole new gnome desktop, I only want to tell the oaf that
we have a new path for .oaf files. 
 
>  
>   
> >   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.
let me describe my idea what I want to change the oaf,  in some detail.
  Firstly, I will install a evolution in a nfs share directory, and write
a script like "startev" to start it. 
In "startev" , I will export PATH, and OAF_ACTIVATION_PATH to the nfs direcotry,
and also export 
a new env virarable  OAFNAME="myEVO". Let me explain the use of this env
variable,  
when the evolution calls the oaf_activate, it will not check "oaf-register.lock",
but oaf-register-${OAFNAME}.lock and so does with
other oaf-used , located in /tmp/<orbit-socket-tmp-dir>. Thus I can
actually run another oafd and this oafd will search oaf file in 
the nfs directory I tell it while the orginal oafd does its own work seperately.
 Yes , it maybe cause some performance issue, but for desktop user, not a
big problem and need not end-user to config his desktop with expert knowledge.

Is that a good idea ? if so,  I can help to write codes to implement this
function ?


> 	Regards,
>
> 		Michael.