From: Filip Spacek <spacek@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 25 Feb 1999 09:09:52 -0500 (EST)

Re: libGGI3d -- ready to code?

On Thu, 25 Feb 1999 Daemonprince wrote:

> On Tue, Feb 23, 1999 at 10:13:44PM -0500, Filip Spacek wrote:
> > I don't think I understand you here. By asking for Interface X do you mean
> > asking for a module with a certain COM id? If that is true how do you
> > know the id to begin with? Standards? (no-no)
> > 
> No asking for modules that have interface X. You will get list that contains
> 0-N. You profile 1-N and pick best (normally fastest) module. You get the
> id by at compile time knowing Id X belows to interface Y which you want to
> make use of.

but then you are limited to id's which are known at compile-time. The only
way to use some other module is to make sure that the module has the same
id. But we cannot guarantee that. If two companies develop the same module
with the same interface, which do basically the same thing for their
respective hardware, they will not go and consult each other to make sure
that their ID's are the same (I'm ready to bet you $100 on that ;-) )
This way we will have to write a module that knows about *both* of the
ID's (bloat)

> > If by asking for Interface X you mean asking for a module with certain
> > type of interface, then you have to have a way of specifing the interface
> > (such as the structure I described in earlier email) and in that case what
> > do you need the id for?  
> > 
> The Id is just a nice convenient way of using already existing tools so
> we dont have to re-invent the wheel. Using COM or something similar means
> that we dont have to be monolithic. We can decide what to link to at run
> time but we decide what we are going to talk like at compile time.

ok. Let me just sum it up. During compilation some sort of script (invoked
from make?) will request an interface id. It will have to provide the type
of module and description of interface to libGGI3d and libGGI3d will
assign an id depending on whether there is already such an interface and
whether it is of the same type of module.

But then we have a well known problem. Say if you have a bump mapper, and
another module which uses this bump mapper. The module knows about the
bump mappers interface, everything is fine. But say you make another bump
mapper with exactly the same interface, then this one should have the same
id as the original one. But this won't happen unless you have the original
one installed on your computer as well. Otherwise you end up with
incompatible id which the module that used the original bump mapper won't
be able to use.

I think that there may be even more problems than this. Basically the way
I see it anything that has "compile-time" in it is not the way to go.
Modules will be developped separatelly by many people (companies?) maybe
even distributed as binary only and there is no way to make sure that
everything is in sync. I think that *every* part of the recognition should
be done at run-time so that everything can work with everything.

-Filip