On Mon, Nov 08, 1999 at 12:02:25AM -0800, Michael I. Gold wrote:
> At 07:04 PM 11/7/99 -0800, you wrote:
> > Both client and server must know about the extension, so it doesn't
> >matter how many $DISPLAYs are out there on the Internet - only what
> >extensions are implemented in the client libraries the application is
> >running against.
>
> But this is a sucky limitation. As long as we're going all out i believe
> we need to design a mechanism which supports dynamic GLX protocol templates
> so the client doesn't become the limiting factor.
The notion is appealing, but I consider it impossibly hard in the
general case. Take the existing handcode routines in the SI - if it were
so simple to automatically generate GLX wrappers from the spec file,
then we wouldn't have any, but there are a lot. And the non-handcode
generator scripts are pretty hideous as is.
Consider parameter validation, client state manipulation which must
also interact w/the server to keep them in sync, hideousness of image
encoding, scalar and pointer parameters, encoding size dependent on
particular argument values... how would you describe fullblown 4D image
packing/unpacking on the client, for example, when it must reach into
context-dependent client state to even have the state to do it? I
suppose one could ship bytecodes for a protocol wrapper from the server,
but overall I don't think any such mechanism is going to to be feasible,
robust, important, or designable in the next few weeks prior to the ARB
meeting.
Here's a strawman mechanism to address the earlier objection about
needing to query each driver DSO even if you don't use them: each DSO
has a parallel flat-text file listing known extensions it exports.
Server config mechanism identifies these along w/driver DSOs, or they
use a consistent naming convention, or they get collapsed into a single
registry by some external mechanism. GLX reads all of them on server
startup and a priori knows all possible extensions supported by the
client.
Jon Leech
SGI
