From: Aaron Van Couwenberghe <vanco@sonic.net>
  To  : ggi-develop@eskimo.com
  Date: Mon, 8 Feb 1999 07:03:53 -0800

Re: GGI3D and CORBA (was Re: libggi3d)

On Mon, Feb 08, 1999 at 09:25:53AM -0500, Aaron Gaudio wrote:
> And lo, the chronicles report that Graeme Gregory spake thusly unto the masses:
> > 
> > IDL and CORBA are seperate concepts. IDL is purely used to define the
> > interface to something.
> 
> But is there any IDL compiler that is not associated with an ORB? My
> understanding was that if I compile my IDL with something like ORBIX or
> ORBit, the implementation parts of the IDL compilation will use the ORB.
> Since preferably I'd be using the interfaces defined and not the implementations
> how could I avoid going through the ORB service?
> 

Yes.
And no.

Here's how it works. The 'ORB' as you call it is a daemon that takes network
requests and forwards them to its local communication libraries. If all
clients that are local are just linked directly with their language's
implementation; if a communication needds to cross language boundaries, then
some shuffling occurs for it to get from point A to B, but the heavy parts
of the ORB still remain asleep; it's usually all handled by the shared libs.
	Of course, this is all implementation specific, and not required by
the CORBA spec.

And yes, usually ORBs are associated with an IDL compiler. after IDL has
been translated/compiled/linked alongside the implementation of your client
(or server), it is linked to the appropriate shared libs. This is because
each ORB vendor decides on the effect of translation, and the required
semantics internally to their product.
	However, local invocations can *still* bypass the heavy parts by
keeping all requestors/objects at a local level with shared links; as I'll
point out later this isn't exactly ideal.

> 
> This is the part I don't know about. Could you elaborate...how does CORBA
> know if I'm in the same address space, if I'm using the interface objects
> and not the implementation ones...or do I have to use the implementation
> objects directly?
> 

That's something that's in the scope of an 800 page book.

however, I'll say NOW that CORBA is *not* ideal in any way (in fact it is a
waste) for low-level APIs. You add a significant level of bloat, and a
significant amount of lag -- a higher number of invocations have to be made
in order for a request to reach its destination. Same with returns. Usually
this is around a factor of five or more.
	The thing CORBA is useful for is encapsulation of high-level
services for sharing across a network.

	For example, berlin. I'll make this quick.

	Berlin's only contact with CORBA is *way* above its implementation
level. libberlin contains all classes that are required by the core, and all
low-level calls to be made on them. Additionally, it defines extreme
high-level points that programmers will want to use.
	For example: our drawing API, for remote connections (or local),
cannot consist of only line drawings and bitmap vectors. Consider the sheer
number of calls that must be constructed, and then how long it takes to
construct each over a network. 
	No, berlin also has a hot-swappable module that defines higher-level
drawings (using what is defined in libberlin, through CORBA) which just
about every programmer will use. These include simple boxes, beveled things
like polygons, paths, etc.
	This is the layer that clients communicate with.

You have to think, will GGI ever benefit from CORBAfication? I doubt it.
Will constructs on top of it, like Mesa and/or a directX drop-in?
definately. Put things in their appropriate places. CORBA is for an
interface that expects network traffic or cross-language modules -- this is
the second acceptable use. Any other reason is just bloat and slowdown.

-- 
..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