At 07:27 PM 9/16/99 -0600, you wrote:
>                       That's why I'm pushing for this concept that
>the driver would be able to manage its own top-level dispatch table
>(through a well-defined API of course!).

Through an API?  I kind of like this api:

   gc->currentDispatchState->MultiTexCoordPointer2fARB =
__glim_MultiTexCoordPointer2fARB;

Why should it be more complex?

>Nothing prevents the driver
>from maintaining its own second-tier dispatch tables if desired.

Second tier dispatch?  I'm happy with one tier, thank you.

I think this whole proposal is awfully complex, and for what?  So
applications don't have to manage seperate ext pointers for the rather
unlikely case of an application calling two seperate drivers with the same
extensions in one machine.  In practice, this is not a huge problem, and
hardly warrents the amount of debate we have seen so far to try to "fix"
the problem.  The Windows mechanism seems to work just fine, and I see very
little benefit from such a complex scheme as you propose, which will
involve rewriting all dispatch table management within every existing
driver, and in a manner incompatible with the existing implementation.

We will probably never agree on this, it seems, so I'm going to stop
debating it now.  There has been very little input from other implementors,
and I would be interested in hearing more of their opinions and less of
mine.  :)

Thanks,

 -- Michael

Reply via email to