[Openal-devel] draft 1.1 spec v1.4 up

[Sven Panne]

Brian Matzon wrote:
> Garin Hiebert wrote:
> 
>> I just posted a new draft version of the OpenAL 1.1 spec.  This one 
>> incorporates all the feedback I've received over the past week and has 
>> undergone some editing for consistency in naming conventions and 
>> layout.  Try it out -- it's in the Documentation section of the website.
> 
> One thing that, unfortunately, doesn't seem to have been "fixed", is the 
>  ALC_EXT_enumeration extension.
> 
> It still returns a list of devices using a \0 as a seperator. This is a 
> really really poor decision, and has been made for the sole reason of 
> being able to use alcGetString which returns one string with all devices 
> in it.
> 
> Besides the obvious bad decision of using \0 as a seperator, I have some 
> very serious problems in implementing this extension in our java 
> binding, since I cannot *ever* return a Java string having multiple \0's 
> in it. I am unsure about how to fix it, unless we simple choose another 
> seperator - though it brings along its own issues. I would however like 
> to voice my concern about the current implementation.

Hmmm, the only issue I see here is the strange duality of a single query,
but that's just an aesthetical issue. Regarding the "\0 problem": I fail
to see a real problem here: On the native side, Java only has UTF-8 (almost)
and UCS-2 (almost), so you have to do some kind of conversion natively,
anyway. So a \0 separator seems to be a minor issue. The *real* problem in
my opinion is the encoding: OpenAL basically talks only about bytes, but
not about any encoding. This is not only a problem for Java, but for e.g.
Haskell, too, where characters are Unicode. So the question here is: Which
encoding is used for all those char* (and variations) values?

Cheers,
    S.