[omniORB] omniidl-generated file size

Aaron Van Couwenberghe vanco@sonic.net
Tue, 2 Feb 1999 19:13:17 -0800


On Tue, Feb 02, 1999 at 05:31:48PM +0100, Renzo Tomaselli wrote:
> Hi OmniORB developers,
>     setting up applications made up of many modules is becoming an issue as far as total size is concerned (at least on NT). Omniidl generated skeleton files are constituted out of three main parts:
> 1. helper stuff for values;
> 2. proxy methods;
> 3. skeleton methods.
> Implementations need 1 and 3; clients 1 and 2. All the others only 1 (all things such as IDL type definitions, no interfaces). Now every module has to include all of them; this makes complex applications pretty heavy, particularly when they are almost colocated.
> What about emitting the above parts on demand, according to a compilation parameter ? Or any other suggestion ?
> Thanks,

Yes, the berlin group has noticed this in a major way. Before the recent
interface reorganization (which makes things a little less flexible...) our
communication library (linked skeletons into one shared lib) was more than
seven megabytes from 115k of IDL.
	Take a look at the way TAO accomplishes this. Upon parsing an IDL,
tao_idl emits three groups of files: C.{h|cc|i}, S.{h|cc|i}, and
S_T.{h|cc|i}. Personally I think this is a bit of overkill, as it makes
things overly complicated.
	However, omni could benefit from this scheme. the S_T group is what
defines needed server templates (helper stuff?); the S group defines skeleton
methods; the C group defines proxy methods.

Now, we're down to 2.5 megs because of reorganization, and the interface
won't be changing much. so we don't *need* anything more fine-grained
although it would help a bit ;)

Also, another question, about how omniidl generates skeletons. I've been
thinking about the DynSK created for every interface regardless of whether
it uses dynamic any's. Is there a way to just have omniidl autodetect this
and only generate what is needed, eliminating the need for this split?
	I am not completely familiar with the corba spec with regard to this
issue. so if my take is wrong feel free to correct me ;)

-- 
..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org....
	Berlin:			http://www.berlin-consortium.org
	Debian GNU/Linux:	http://www.debian.org

Nullum magnum ingenium sine mixtura dementiae fuit. -- Seneca