[omniORB] Implementation Repository

James Waller jameswaller@coralwave.com
Thu Mar 6 15:52:02 2003


First, apologies for the long post.

The locations of header files is something I've thought about before, 
but at the time I decided against moving them. The reason was that I 
thought the include/ directory should be kept for header files that were 
to be included by external programs. I wanted to keep the internal 
header files separate (such that they wouldn't form part of the 
installed package), but then again it's possible that other programs 
would like to use header files currently inside the common/ directory. 
The imradmin program requires some of them, for example.

A server-side python layer should just need to replicate the 
ServerProxyPOA class in the ServerProxyPOA.h header file using python 
code, probably consisting of no more than a single file. No C++ code 
should be necessary. Everything else would be done as normal through the 
omniImR::Repository interface.

The code in common/ is built into a static library at present, so a 
shared library will be easy. The name of the library (libcommon.a) will 
need to be changed - originally I was not going to make this library an 
installable component, you see. libomniImR.so sounds good enough.

I think the revised directory structure could look like this:

config/        Autoconf macro files
doc/           User documentation
src/
     common/    Source files for omniImR support library
     daemon/    omniImR Daemon source files
     imradmin/  imradmin source files
     examples/  Stuff originally in test/
         EchoClient/
         EchoServer/
         PREchoServer/
include/
     common/    Header files from omniImR support library
     daemon/    omniImR Daemon's internal header files
idl/
man/           Manpages for omniimr and imradmin

The sample config file would be placed at the top level. This is closer 
to the omniORB package's structure. What do you think?

I will post another tarball soon. I am also placing doxygen comments in 
all the classes, so we will have documentation of the internals. There 
will also be manpages for the omniimr and imradmin programs.

Cheers,
James


Thomas Lockhart wrote:
> Some additional comments on directory structure and build environment:
> 
> o autoconf (for the platforms which support it) can be used for this 
> package. The config/ directory would conventionally contain autoconf 
> macro files, so perhaps the omniImR.conf file can live somewhere else?
> 
> o As autoconf is integrated, the package would be configurable to look 
> for an existing omniORB installation, just as is currently done with 
> omniORBpy. autoconf supports having separate but cooperating configure 
> scripts in child directories. So we can put in autoconf support in the 
> standalone tarball, and carry it forward if omniImR is moved into the 
> omniORB tree later on.
> 
> o common/, daemon/, and imradmin/ contain both header files and cc 
> files. There is also an include/ directory which contains only a single 
> header file. Should the includes be consolidated into the include/ 
> directory? Especially if there may be other products (e.g. a server-side 
> python layer) which need to see some of the header files to be built.
> 
> o If the "common" code is not yet built into a shared library, we will 
> want to move toward that. What would the library be called? Something 
> like "libomniImR.so"? Perhaps common/ could become src/lib/ (or ??) in 
> this tree? And the shared library could be built into lib/ ?
> 

Cheers,
James