From: Aaron Gaudio <icy_manipulator@mindless.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 24 Feb 1999 18:14:00 -0500 (EST)

GGI3D: interfaces (was Re: libGGI3d -- ready to code?)

I've followed this thread for a while and would like to reiterate my
opinions which I've stated formerly on this list wrt GGI3D, as well as
propose some new ones.

Interface IDs:

I mentioned before, and several others agreed, that strings (specifically
null-terminated char arrays) were sufficient to distinguish the 
interface types of the input and output of a module. Can it be done using
ints? Yes. Does the computer care one way or another? No. Is it a little
more efficient to use ints? Yes. Does that efficiency really matter? No,
because the majority of the use of such interfaces (i.e. to check that
two modules can link together in a pipeline) will not be done beyond 
initialization time. Since string interface descriptions are easier for
the developer to understand, easier to maintain, and less prone to namespace
clashing, it still seems that is the best way to go.

My original conception of a module interface was merely something the GGI3D pipeline uses to determine the type of the input and output of that module. In
other words, type-checking. Type checking provides a means to catch silly
errors made by the programmer, not a means to determine the state of the
arguments passed.  Similarly, in GGI3D, type checking (via interface comparison)
is a means to indicate that whoops, two modules don't fit together. I'm really
of the mind that this may not be necessary at all. Type checking in C is
compile-time and so incurs no overhead. Interface comparison in GGI3D is
run-time and does incur overhead, and since it is a system to prevent stupid
errors, I wonder if type-checking is a good idea. Let me contrive some
examples:

You are running a GGI3D-enabled app. A GGI3D pipeline is set up during
initialization such that two modules whose corresponding interfaces don't
match up (and assume there is either no facility for translation or there
is no translator available). GGI3D is now in an unusable state, since it
cannot know what depend on that pipeline, and how important either of those
modules are to the pipeline. It must abort initialization and so the
app will abort as well. There is no error-recorvery possible.

You are running a GGI3D-enabled app, except in this case, GGI3D has no
type checking. At initialization the same thing happens, only in this case
initialization is successful becasue GGI3D did not catch the interface
mismatch. The application runs normally. Now, if the application happens
to never use that pipeline (lets say it wasn't the main pipeline), then
nothing goes wrong. If it does, we'll more than likely get a core dump
for our troubles. In this case, there is no error-recorvery possible 
either.


So with type-checking (using any of the proposed interface definition methods),
what have we gained? The ability to catch potential errors early during runtime.
What have we lost? The time and space overhead of type-checking and storing
interfaces. In either case, when an error occurs, chances are the user will
not have a clue as to what caused the error or how to fix it, unlike with
C, which typically when there is a type mismatch found by the compiler,
the person who gets the error knows how to fix it. Type-checking is a tool
for developers, not for end-users. Other uses of RTTI (run-time type
identification) are not as applicable here as they are in component-based
systems (such as COM, EJB, CORBA). In a component based system, new
components may be added or removed from the system and may need to interoperate
with an arbitrary collection of similar components at run-time. This is
not the case with GGI3D; the set of modules available is a known entity,
the pipelines are (more or less) built before runtime (that is, in an
initialization step; or even during a linking step), and modules are not
arbitrary, things flow down an individual pipeline in only one way. I suggest
non-runtime tools to check interface conflicts before runtime, using
module meta-data which is not part of the binary module code at all. If
runtime knowledge of that meta-data is necessary, then it can be made
available via auxilliary functions in the API, so that the costs associated
with interface lookup and comparison are only paid when explicitely requested.

As for interfaces which somehow describe the state of the data (for instance,
knowing that the input is not only of type List<3dCoordinate> but contains
coordinates which have been translated to the view reference coordinate
system), I am of the mind that this is not necessary in the least. Its 
usefulness at runtime is very limited, and it incurs a significant amount
of overhead and development complexity. Again I would support a means of
external meta-data which describes the module itself (the hierarchial 
registry as previously discussed). Whereas one could do just about anything
conceivable with a list of 3d coordinates which have been translated to
the view reference coordinate system, in any order, it becomes clearer what
state the data is in by examining the context of the modules passing it.
For instance, if all I know is that I have a list of such coordinates,
I don't know if they've undergone HSLR (hidden surface line removal) yet. If 
I were to blindly insert a new HSLR module into the pipeline, I might
be tempted to simply stick it after the first module which outputs a list
of such coordinates. Little do I know that in fact there already was another
HSLR module in the pipeline. Or if I were installing a new Volumetric clipping
module, I might end up installing it after an HSLR module in the pipeline,
at significant cost to efficiency (since clipping is easier, I believe, than
HSLR). In the end, to achieve what I want to achieve correctly, I am forced
to look at the module meta-data itself, in order to find where to insert
a new module and which modules the new module may be replacing/disrupting.
There is no mechanism which I can see that can automate this for 
arbitrary modules. The utility doing this sort of work, whether it be
a standard utility for building the default GGI3D pipelines or a game
modifying the pipelines at runtime, will have to be specialized to the
modules it is installing and the pipeline it is modifying. To claim otherwise
is to deceive the developer into thinking he doesn't have to do as much work
as he really does, and is really just asking for trouble. Meanwhile, it incurs
significant overhead.


Finally, I'd like to reiterate my objection to any kind of embedded 
benchmarking in GGI3D. My philosophy on this is that slower modules should
not be in the pipeline in the first place, and any speed tests should be
done, if at all, by an external utility, for instance, the utility used 
to set up the default pipeline. Information gathered by any such benchmarker
should not be contained in the module meta-data and should not be available
via the GGI3D API. If a program wants to use such data, it will have to do
so without the help of GGI3D. It is my contention that if a program using
GGI3D (not configuring it) has to ask which module is faster, then GGI3D is
not fulfilling its promises. The program should not have to ask which module
is faster, because GGI3D should already have the fastest configuration set
up. Any run-time modifications to the pipeline will be limited and highly
controlled, and will, IMO, be based on situation, not module availability.
(For example, a program may choose to disable/enable the alpha-blending module,
but it should never have to ask the GGI3D runtime which alpha-blending
module is the fastest).

I'll let you rest your eyes now ;-)

-- 

¤--------------------------------------------------------------------¤
| Aaron Gaudio                   mailto:icy_manipulator@mindless.com |
|                    http://www.rit.edu/~adg1653/                    |
¤--------------------------------------------------------------------¤
|      "The fool finds ignorance all around him.                     |
|          The wise man finds ignorance within."                     |
¤--------------------------------------------------------------------¤

Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.