From: Filip Spacek <spacek@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 19 Feb 1999 22:03:27 -0500 (EST)

Re: libGGI3d -- ready to code?

On Fri, 19 Feb 1999 Aaron Gaudio wrote:

> The direction I think we were going was to have all interfaces consist
> of a single input object and a single outpout object, so your example
> would turn into this:
> 
> typedef struct {
> 	int arg1;
> 	long arg2;
> 	float arg3;
> } foo_input;
> 
> void drawtriangle( struct foo_input );
> 
> This allows the functions to be dynamically called without requiring
> the overhead of something like CORBA to marshal arguments (because they
> in effect are already marshalled).
> 
> > Well, string seemed to be the best from the point of view of speed and
> > flexibility. But the way I see it just a simple C++ish name mangling is
> > not sufficient. What would be needed is a _description_ of the data
> > structure. For example how would one go about describing interface for a
> > BSP-tree rasterizer? (ok, some people may say that that is way to specific
> > to be in libGGI3d, but that is the beauty of libGGI3d -- it cannot be
> > bloated and also having the actual tree might help in some other parts of
> > the pipeline). 
> 
> You would describe the interface of the BSP-tree rasterizer the same as
> any other rasterizer. GGI3D will only perform type-checking when manipulating
> modules in the pipeline, it won't perform logical analysis. All it will
> tell you is that you module can or cannot fit in the pipeline at a specific
> spot, whether it makes sense to do so or not is up to you. There will
> be other mechanisms for determining what a module does. Beyond this, if you
> want you module's interface to be compatible with other modules, you'll have
> to follow their documented interfaces. It's an interesting thought though,
> I'll parse some ideas in my mind...

(note that this probably doesn't come from my head, that is what I have
figured out from previous posts. if there is some horrible shortcomming to
what I'm suggesting which has already been discussed in the past feel free
to redirect me to mailing list archives)

I think this is quite a limitation. This way a module is limited only
to interfaces the module directly above recognizes. If libGGI3d had a
logical description, it could "make it fit" pretty much anywhere. This
would all be of course performed during pipeline construction so there
would be no overhead. The fitting would be made using so called
translators which would adjust the data as needed. Translating data would
obviously be quite an expensive operation, so during the construction of
the pipeline, libGGI3d would have to take care to use the least number of
translators. libGGI3d could also get the aproximate cost of the
translation (for example I would not want my 5000-node BSP-tree go through
a translator) 

Note that this whole mechanism would not serve to determine what the
module does. (I think this has been resolved with a registry of sorts,
which is a very good idea) The only thing it does, is that it makes sure
the data is in a certain format and if it isn't it passes it through a
translator. (libGGI3d does no checking so if you pass a nonsense, libGGI3d
would pass it through a translator, and even bigger nonsense would come
out)

The only problem with this is how to get libGGI3d to generate pipeline
only once. For example (stupid example but it will do) if a module first
calls a triangle rasterizer and then it calls a shadow generator. libGGI3d
cannot automatically assume that it has to pass the data through a certain
translator because there are two different interfaces comming out of this
module. What would libGGI3d have to do is figure out all the different
*types* (from the registry) of modules this module calls and the
associated interfaces. Then when the module actually calls these other
modules libGGI3d would call the appropriate translator depending on the
type of module called. Another option would be to figure the the
translator at run time, but that seems way too inefficent.

<snip CORBA introduction>

ok. It seems clear enough to me. IDL is not the way to go. I will not
solve any of the problems that are with structure passing and it only adds
overhead.

-Filip