From: Daemonprince <dp@khazad-dum.freeserve.co.uk>
  To  : ggi-develop@eskimo.com
  Date: Sat, 20 Feb 1999 23:10:37 +0000

Re: libGGI3d -- ready to code?

On Sat, Feb 20, 1999 at 01:30:32PM -0500, Filip Spacek wrote:
> > The only problem I have with COM is this messiness that you mention.
> > The GUIDs though they may be unique are not human readable and this
> > means extra overhead of making GUID to person converters. Ever tried
> > finding an incorrect registry entry in windows :-)
> > 
> > Otherwise from what COM work I have looked at in my Job defining a COM
> > interface is the same as one in IDL. The language is even called mIDL.
> > 
> > But the uniqueness of the identifier is a good winner, Java almost has
> > this with its internet address tagged on the front of classes thing. But
> > big companies have already broken this. No-one as far as I know have
> > messed up COM though.
> 
> I don't think that unique identifier is enough. We need something that
> would allow us to recognize what kind of data the module expects. 
> 
Sorry should have gone into more detail, the unique identifier if useful
because otherwise modules could get confused.

Hopefully I remember this right but I think under COM you can use the
unique identifier to find the interface to a module/COM object. Sort
of similar to the repository in CORBA.

Buit I do agree if we want the sort of pipeline builing abilities being
talked about. Some way to discover where in a pipeline a module sits is
needed.

I think it may be neccessary to limit a module to certain type it can
take into it and certain types it can output. Other wise the number of
combinations tends to infinity. What we maybe need are a set of generic
type such as list of trianles, surface patch, list of vertexes and
a modules must take in one of these fixed types and output the same
or another. The last module in the pipeline of course outputting Z buffer
and pixel buffer points.

Graeme