[Openal] Status of OpenAL 1.1 on OS X

[Sven Panne]

> -----Original Message-----
> From: openal-bounces at opensource.creative.com 
> [mailto:openal-bounces at opensource.creative.com] On Behalf Of 
> William Stewart
> Sent: Freitag, 11. August 2006 20:11
> To: David Guthrie
> Cc: openal at opensource.creative.com
> Subject: Re: [Openal] Status of OpenAL 1.1 on OS X
> [...]
> With this existing situation (OAL 1.0 alut declarations and 
> ongoing freealut definitions of these same symbol names) 
> there is nothing we can do to resolve the conflict this 
> causes (as we don't plan on shipping freealut)

The last clause in parentheses is actually the root cause of the
problems on OS X.

> One way I could see to resolving this is:
> - make sure its clearly marked that the existing alut 
> function names are marked as deprecated.
> - freealut should rename their functions so that they don't 
> conflict with the existing 1.0 declarations (which of course 
> is the problem you are seeing).

Well, I hope that you are joking here: About one year ago, there was an
epic discussion on this list about the future of the ALUT API. It was
decided to split the ALUT part off the OpenAL core, and I can't remember
any objections against that. Complaining now is a little bit odd. It was
a very deliberate decision, because the old ALUT API was not usable in
real-world programs and it varied depending on the platform.
Furthermore, there are techniques for legacy programs proposed on:

 
http://www.openal.org/openal_webstf/specs/alut.html#BackwardsCompatibili
ty

Using LD_PRELOAD works fine on Linux (and similar platforms), I can't
comment on DYLD_INSERT_LIBRARIES, but I guess that Mac OS X has some
mechanism that works, too.

As already proposed, shipping two frameworks (one OpenAL 1.0 including
ALUT and one OpenAL 1.1 with ALUT being a separate framework) looks like
the right solution for Mac OS X if one wants to be conservative. The old
framework should be marked as deprecated and could be removed in future
Mac OS X releases. I have to admit that I don't know the mechanisms of
frameworks and handling versioning on Mac OS X in detail, but I'm quite
sure that there is some way to handle this elegantly. And even if not:
Continuing to ship a combined OpenAL/ALUT is the worst solution.
Shipping no ALUT at all would be better, because people could then
easily compile/download a separate ALUT framework without any trouble. A
separate ALUT framework shipped with Mac OS X would be even better, of
course. Are there any legal problems with freealut (which is LGPL'd)? If
yes, please contact Steve and me, I'm sure we could find a solution.

What will definitely *not* happen is that the ALUT spec, which exists
for a year now and has seen several minor revisions with no complaints,
will be changed completely just because Apple wants to keep their stuff
in a form like they always did. One of the cornerstones of any
respectable API is stability, and renaming all API entries will
completely break all code out there, which would be ridiculous and
effectively kill ALUT.

Cheers,
   S.