In your message of 18 September 1999 you write:

> | Maybe that's a simply language problem, but for me both views are just
> | different sides of the same coin.
> 
> Its a question of degree.  We are clearly failing to reach a "meeting
> of minds" when it comes to the implementation details for  allowing
> mult-vendor drivers to coexist on the same box, so we should stop
> allowing those disagreements to derail the effort of making it possible
> to run an OpenGL application on a mono-vendor linux box and reasonably
> expect their application to work.  If this is the best we can
> reasonably do for the moment, then that is all we should do.  The goal
> is to allow OpenGL to move forward quickly for the benefit of application
> writers.

Maybe the disagreement comes mostly from the fact that many people try
to mix the API issues with the implementation issues. The point I'm
trying to get across is that a ABI for OpenGL on Linux has to allow
the same application run with different implementations of libGL. Why
? Even if there would be only one libGL, you still have to deal with
the issue that there is a version 1.2 of this library and there will
be a version 1.3. And of course every LINUX vendor recompiling libGL
would add their own fixes, impovements, and other potential
problems. Concentrating exclusively on one simgle implementation will
lead to exactly the same problems that are present in the windows world.

In order to allow applications vendors to port applications to
linux and expect them to run with on variety of distributions and
hardware scenarios, we have to care about forward and backwards
compatibility. And this means not to be focused to much on a given
implementation. 

This is what gets me frustrated here a little bit. Alan has shown that
it's feasable to implement a dispatch mechanism that makes it possible
to have GetProcAddress() return pointers that are not context
sensitive. Now lets move on and figure out which semantics we want to
have, rather than to get stuck on finding out how many other ways 
exist to do the same thing, that IMHO is really irrellevant form
the applications point of view, as this one will only see the pointer
returned by GetProcAddress().

- Thomas
-- 
             Thomas Roell   /\         An imperfect plan executed violently
             Xi Graphics   /  \/\ _     is far superior to a perfect plan. 
         [EMAIL PROTECTED]   /   /  \ \     
                         / Oelch! \ \             George Patton

Reply via email to