[HOpenGL] HOpenGL1.02 on Sun's?

[C.Reinke]

> 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