From: Filip Spacek <spacek@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Sat, 20 Feb 1999 13:30:32 -0500 (EST)

Re: libGGI3d -- ready to code?

On Sat, 20 Feb 1999 Daemonprince wrote:

> On Sat, Feb 20, 1999 at 01:00:35PM +1100, Andrew Apted wrote:
> > Has anyone considered something "COM" like ?  The basics of COM seem
> > pretty suitable, being :
> > 
> >   -  Interfaces are named by 128 bit "GUIDs" (Globally Unique
> >      Identifiers).  They are practically guaranteed to be unique, so no
> >      real chance that the interfaces of two separately developed modules
> >      will clash.
> > 
> >   -  Each "component" can have multible interfaces: whenever you have
> >      one interface pointer, you can use the standard "QueryInterface"
> >      call to see if that component supports a particular interface.
> >   
> >   -  Interfaces are immutable, once they are "published" they cannot be
> >      changed, so there is no problems of things breaking because someone
> >      altered the ABI.  To add new features, you need a new interface.
> > 
> > CrystalSpace is using COM, which is why I mention it.  The COM-ified
> > code looks rather messy (IMHO), but works OK.
> > 
> 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. 

Example (stupid):

a polygon drawing module accepts NULL terminated array of triplets
defining the polygon. But now nVidia released a binary only polygon
drawing module (as if) which accepts a NULL terminated array of
quadruplets. The only way for you to make any use of the module is to
rewrite *all* the modules the ever used the polygon drawing module. What I
suggest is to have a sort of language which would allow us to recognize an
interface and allow us to change the data when needed.

polygon with triplets would be defined as:

"((double)3)3+ NULL"

polygon with quadruplets would be defined as:

"((double)4)3+ NULL"

(this language is something I made up just now so it would have to be
changed quite a bit)

now that libGGI3d knows that the new module accepts quadruplets it can
plug in the translator (which would be just another module) and the shiny
new hardware rasterizer can be used. Note that this interface recognition
would be done during pipeline construction and once the proper translators
are estabilished no interface checking is done.

The only problem I see with this is that translation could be quite
expensive operation but that is up to libGGI3d to decide which is
faster -- translator or not. Also, we would still have a limited set of
translation modules, because we could obviously not account for every
possible translation, but they would be much more reusable at different
points in the pipeline.

-Filip