On Mon, May 08, 2000 at 10:31:46AM -0600, Brett Johnson wrote:
| [EMAIL PROTECTED] wrote:
| >
| > Reduce the problem to a two-way choice. Since Option B
| > subsumes Option A, we'll go with B vs. C.
|
| Jon's original "A" option:
|
| A) Do nothing (current oglbase proposal). glext.h must always be
| #included explicitly by the application.
|
| Allen, I don't believe that your new, revised description of "B"
| subsumes "A" at all. In fact, it directly contradicts the original
| "A" that we all voted for by explicitly #include'ing glext.h in one
| case, and making the behavior wishy-washy and undefined in the default
| case. ...
Hi, Brett.
People have very different understandings of what options B and C were
in the original vote. If you go back and check the archives for the
first and second week of April, you'll find that quite a bit of
discussion took place, even during the vote, but there was never a
resolution of the issues. This became even more apparent as Michael
and I talked to people offline during the past two weeks.
With regard to the wishy-washiness of all three options in
compatibility mode, unfortunately that's just the way things are in
the field, right now. I thought it important to make that perfectly
clear, so that people understand the problem we face. We need option
B or C to nail down new semantics precisely because option A and the
compatibility modes of B and C are so wishy-washy.
To put it another way: We're already in a situation where gl.h from
any given vendor is not likely to be compatible with gl.h from any
other vendor (with respect to extensions). Option A and the "upward
compatibility" modes of options B and C can do no better; they can
only offer compatibility between old and new versions of gl.h from the
same vendor. The "new semantics" modes of options B and C provide
cross-vendor compatibility for extensions, and that's why it's
essential to adopt one of those two (rather than option A).
| ... Therefore it's utterly improper
| to summarily reduce the vote to these two options.
It's a dirty thankless job, but someone's got to do it.
XFree86 4.0.1 will probably ship in about three weeks. If we
(oglbase-discuss) don't reach a consensus pretty soon, then people
providing gl.h for that release will have to choose a gl.h/glext.h
structure on their own. It would be nice to avoid that.
| ... However, it seems
| clear that, due to the existance of glXGetProcAddress, the OGLBASE
| compliant default should be to typedef the extension functions, but not
| prototype them (as in your new "C" option).
Yes, I think that's the right behavior. Some people understood that
to be part of the previous vote, and others didn't. So we're trying
to clarify it this time around.
Allen
