Alas, I don't. But if you use Mesa (http://mesa3d.org/) instead of SUN's OpenGL, it should work, although slowly. Fast 3D graphics over a network is a bit ambitious, even more without GLX. :-}
hmm, I'm not at all sure I understand the connections properly. IIRC, I got an error about missing GLX, but the Suns do have GLX (somewhere). If you're using exceed without any GL support, does mesa translate from GLX to X on the client-side, or am I missing yet another thing in my installation because of non-standard paths? The mesa faq (outdated) seems to suggest that mesa would do the translation even for dumb X-terminals, but I wonder whether it will be worth using a software-emulated OpenGL implementation - the idea was to make it easier for other local users to have a try and play with whatever I'm trying to come up with, so anything that won't look good, well, won't look good, if you know what I mean.. And isn't it the role of GLX to translate between GL and X protocol? If it could do so client-side, the X server should not need any GL support. But I think the "missing GLX" message was display-specific, thus referring to the exceed X server, not to the client Sun machine. So is GLX really an extension of the X protocol, needing both client- and server-side implementations? I'm confused..
It's just the other way round: The API is exactly specified, *including* all token values, see the central registry for all extensions (http://oss.sgi.com/projects/ogl-sample/registry/).
That is just the *extensions* registry - the API itself is now in the hands of the ARB, and the specs there do not seem to define any values, only their names? The backlink to the API docs on the extensions registry page is broken - should be to: http://www.opengl.org/developers/documentation/ Interestingly, the extension out of which the now standard 3d textures parts developed doesn't seem to mention the missing name - seems there were some renamings involved when moving that extension into the standard? Although the extension registry includes allocation policies for enumerants, I remain unconvinced that the standard API includes the values of bindings. It would be nice for all implementations to agree on the values, but is there any place in the spec saying that the values should be those of the original extension (and what about renamings in the promotion process?) or those of some reference include file (is gl.h mentioned anywhere)?
This is the only way OpenGL's extension mechanism can work, and it's the only way a non-proprietary API can work, too: Forcing users to recompile just because some vendor has decided to change some values randomly is not an option in real life. The situation is very similar for X11.
Real life software isn't always sensible.. I thought the very reason for the ABI (application binary interface) http://oss.sgi.com/projects/ogl-sample/ABI/ was that the OpenGL API does not address this (and the ABI is X/linux-specific)? But if the situation is better than I was hoping, that raises another interesting question: How portable are HOpenGL/GHC-generated executables? Obviously, not between platforms;-) but what do they depend on? GHC has otherwise become quite independent, but HOpenGL seems to depend on cygwin? And are the executables dynamically linked to OpenGL, so that they have a chance to work with someone else's graphics-card? In brief, could I "ship" a windows-executable to non-Haskellers and hope for this to work (and not ruin their hardware?-)? Claus