From: Bryan Meredith <bryan@bear-mountain.demon.co.uk>
  To  : ggi-develop@eskimo.com
  Date: Sat, 06 Feb 1999 23:32:53 +0000

Re: libggi3d

Aaron Gaudio wrote:
> 
--- snip ---
> 
> <Bryan>
> 
> Below I mention the list (or map) of modules by function with input and
> output interfaces specified using ints. Text is all very nice but int
> compares are faster.
> I am a little fuzzy on how this would limit developers to 'standard'
> interfaces. For the modules to be pluggable in an arbitrary position
> (even if this doesn't make sense), the 'standard interfaces' have to be
> there - unless, of course, you are developing a totally custom pipeline
> which does not interface with any existing modules. This would lead to a
> large (dare I say bloated) registry of standard interfaces. However, I
> would expect the interface types to settle at some point. No way 32 bits
> worth though ;-)
> 
> <Me>
> 
> The problem I always have with integer ID systems is not that they are
> limited (although theoretically they are) but rather that they are
> overwhelmingly confusing. Even worse, there is rarely a standard for
> numbers outside the range of the pre-defined ones, so there is nothing
> preventing two different authors from defining the same interfaces
> with the same ids.
> 
> As for efficiency, as someone else pointed out (I think), these comparisons
> are not done very often; only when adding or removing modules from the
> different parts of the pipeline. Usually, this will done at initialization
> time based on the stored configuration. Therefore, to worry about the
> efficiency of string (or memory) comparison versus int comparison, IMO,
> is not warranted.
> 

Fair enough.


> <Bryan>
> 
> However, runtime pipeline construction will need to know what they are
> in order to do the connecting.
> 
> <Me>
> 
> Not really. It'll be up whatever is driving the construction to do
> the connecting. In the case of the configuration, the connections will
> really be done already, it'll just be a case of resurrecting the stored
> connections. In the case of runtime-alteration, the client code will have
> to be wise enough to do this. Perhaps there could be some utility classes
> which can provide a little (automatic) logic to the process, but this
> will, by necessity, be very limited (for instance, it may be able to
> tell generally that modules in a certain branch of the type hierarchy
> go before/after those of a different branch).
> 
> <Me>
> 
> >
> > > For example:
> > > Module A has an input type of ggi3d_coord3 <three dimensional coordinate,
> > > standard type> and and output type of ggi3d_coord2 <2 dimensional coordinate,
> > > standard type>, then it becomes obvious that for a module to be chained
> > > after Module A, it has to have an input type of ggi3d_coord2. But you are
> > > not limited to standard types. You could just as easily have this (pardon
> > > any C++isms):
> >
> 
> <Bryan>
> 
> Is my English that crap???
> I thought that I had also said this???
> 
> <Me>
> 
> Not quite the same as you said. My example used strings based on the
> names of the types, whether those types were of standard types
> (such as ggi3d_coord3 or something) or user-defined (such as myRGBColor).
> 

OK - My integer based solution said the same thing but with numbers
instead of structure names - my misunderstanding :-(

--- snip ---

> <Bryan>
> 
> But why?
> There has to be a unique identifier for the each interface. An int
> provides millions.
> Designed a new module type? Have a new module type identifier (again,
> millions)
> 
> <Me>
> 
> But those millions may be chosen randomly (aside from the standard ones).
> I have no question that the available space in theory would not be
> exhausted, but in practice there's no convienient means of establishing
> namespaces. In light of the aforementioned fact that interface-comparisons
> will not happen often during the running of the client, I think the
> benefits of a string (either char* or char[]) based system outweigh the
> costs.
> 

OK

-- BIG snip! ---

I'm looking at mapping the registers from my matrox mil2 across into
user space so that I can put together access functions for all of the
cards' supported accels (the texture stuff will come later but I will
have a go!). I'll probably just hack this in for myself unless anyone
else shows an interest. However, once there is a standard method for
getting the accels across, the access functions will work. Once there is
something firmed up that could carry a modules hooked into the accels
you will be more than welcome to them or maybe even I'll try to write
the module myself.

My time is limited but I would like to help where you want and when I
can.

I do ask questions but I am open to reason (and beer).

Bryan

-- 

Oh Bugger...