From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 4 Feb 1999 15:21:20 -0800 (PST)

Re: libggi3d

On Thu, 4 Feb 1999, Xavier Bouchoux wrote:

> Jon M. Taylor wrote:
> > 
> > On Thu, 4 Feb 1999, =?iso-8859-1?Q?Niklas_H=F6glund?= wrote:
> > 
> > > If I have understood things correctly libggi3d is a very small toolkit
> > > that is meant to link modules together.  These modules all take one
> > > struct as input, and returns another (possibly identical) struct as
> > > output.  Two modules can be linked together if the first one returns
> > > the struct the other one wants as input.
> > >
> > > What is being discussed right now is how to name the modules, and how
> > > to identify which modules can be connected to a module.
> > >
> > > I don't see a reason for why the names should be computer readable.
> > > It seems reasonable to me to let the module authors name their modules
> > > however they want.
> > 
> >         Correct.  The module name means nothing.  It is just a nice "tag" so
> > that a human can browse the module list and understand what the module does.
> > LibGGI3D only identifies modules by their input and output interfaces and the
> > ggi3d_module handle you get back when a module is successfuly registered with
> > the system.
> 
> 
> I don't agree!  (More precisely, I don't really understand..)
> If I am a programmer, and I want to provide a non-standard module with
> my app, I have to be able to insert it where I want in the pipeline, and
> the datatypes aren't enough for this!

	Yes they are.  You can insert that module anywhere in the pipeline
that the module's interfaces allow.  That is *all* you know.  LibGGI3D does
NOT manage pipelines, it gives the programmer better ability to manage
his/her own pipeline(s).  *You* have to take care that you are managing 
your modules intelligently.

> Suppose I have something to do on geometry.
> I reaaly want it to be inserted after the clipping, but the clipping
> actually function doesn't appears in its entry types.

	Correct.  In this case, it might be that you could insert the
geometry module before or after the clipper.  That is entirely up to you. 
LibGGI3D has no way of knowing what you want to do with the geometry 
module.  It only knows that the gemotry module has a particular input and 
output interfaces.

	WOOPS!  Looks like I missed something.  I have been saying that a 
module is completely defined by its i/o interfaces, but obviously the 
*programmer* must have additional info in order to distinguish the module 
from another one that happens to have the same interfaces but does 
something totally different.  For that, you parse the module ident 
string.  Sorry for the confusion.
 
> where am i wrong?

	You appear to be assuming that LibGGI3D itself must be able to know 
what the module does, not just its interfaces.  The programmer using 
LibGGI3D may need that info, but not LibGGI3D itself.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed