Subject: Re: Renaming "portable" - msg#00026

Previous Message by Date: click to view message preview

RE: Renaming "portable"

Perhaps we should mirror what OpenGL does here again and call the current "portable" stuff simply the "sample implementation" (SI). This doesn't necessarily imply that it would run on each and every platform in the world, although that should be the ultimate goal, of course. :-) Furthermore, I agree with Garin that we should remove the unmaintained projects from the trunk. They are still available via the "tags" subtree, anyway. To make my proposal for the trunk more concrete: * Remove "beos" and "mac" (I think the latter is unmaintained stuff for old Mac OS versions). * Rename "linux" to "OpenAL-Sample". * Rename "macosx" to "OpenAL-MacOSX". * Rename "win" to OpenAL-Windows". * In the long run, the stuff from "demos" should migrate to "contrib". * "COPYING" should be moved into the various subprojects (if not already there). There is no need to force a single licensing policy on everybody. * Merge "INSTALL" into "README". Is this OK with everybody? Cheers, S.

Next Message by Date: click to view message preview

RE: Renaming "portable"

[ Sorry for the quoting hell, but Outlook simply doesn't allow any sane form of a reply to an HTML mail... :-( ] I think there is a misconception here: The repository does *not* contain a single project, it contains many of them: The Windows implementation from Creative, the Mac OS X implementation from Apple, the "portable"/sample implementation rooting in Loki efforts, freealut, demos, test, ... Of course it would be nice if the number of OpenAL implementations could be reduced a little bit and there is acutally no deep technical reason why this couldn't be done. But: Unless somebody finances a dozen people or so to work full time on this merger, it won't happen any time soon. To reflect this reality the renaming makes very much sense. Please don't get me wrong: I would *love* to have a single, nicely structured, highly modular cross-platform implementation of OpenAL, which could be shipped by Creative, Apple, Linux/BSD/... distros, but this is a non-trivial amount of work and there are currently working too few people on this to make this a realistic goal. Regarding EAX: I don't see a problem here, it is just an extension to core OpenAL which might or might not be present on the platform the application is running. OpenGL's foo_EXT extensions are similar and nobody had a problem with this. Of course a cross-platform implementation of EAX (perhaps only EAX2) would be great, but not having this is not a show stopper. Regarding the license file: As already mentioned, there are different projects, so there is no need to force a single license onto everybody. And a much more practical reason: A packager will never release the whole repository, but only an individual subproject, so the right place is there. Otherwise the releases won't have any license file at all, which is not good. Cheers, S. ________________________________ From: Richard Hancock [mailto:rjhconsulting@xxxxxxxxx] Sent: Donnerstag, 4. Mai 2006 13:56 To: Sven Panne Cc: openal-devel@xxxxxxxxxxxxxxxxxxxxxxx Subject: Re: [Openal-devel] Renaming "portable" * Rename "linux" to "OpenAL-Sample". * Rename "macosx" to "OpenAL-MacOSX". * Rename "win" to OpenAL-Windows". I think this might be a bad idea. From what I can tell of OpenAL is that it is a wrapper for the difference platforms for the underlying audio API. In my unprofessional opinion, we might want to consider doing it like SDL does. A combination of configure options and #defines. Example: The OSS backend can be enabled or disabled at compile time with a #define OSS_ENABLE (or something to that effect). The sources should probably be organized a bit better to seperate context, device, effects, etc. and platform specfics under that. This should also allow seperation of OpenAL from Creative and Apple (Although both can provide specialized drivers through thier respective update process). Also, if the EAX versions included with OpenAL will not work accross all platforms, it should not be included. No reason one platform should be special treatment in a cross platform library. * "COPYING" should be moved into the various subprojects (if not already there). There is no need to force a single licensing policy on everybody. I would have to disagree. There should be one license for the entire project. OpenAL is supposed to be a single cross-platform library, not 3 projects representing (and in reality functioning differently) one. As both a developer and an end user, having one code base for multiple platforms is preferable to having 3 code bases for 3 platforms. Just my 2 cents. -- Richard J Hancock RJH Computers http://www.rjhcomputers.com

Previous Message by Thread: click to view message preview

RE: Renaming "portable"

Perhaps we should mirror what OpenGL does here again and call the current "portable" stuff simply the "sample implementation" (SI). This doesn't necessarily imply that it would run on each and every platform in the world, although that should be the ultimate goal, of course. :-) Furthermore, I agree with Garin that we should remove the unmaintained projects from the trunk. They are still available via the "tags" subtree, anyway. To make my proposal for the trunk more concrete: * Remove "beos" and "mac" (I think the latter is unmaintained stuff for old Mac OS versions). * Rename "linux" to "OpenAL-Sample". * Rename "macosx" to "OpenAL-MacOSX". * Rename "win" to OpenAL-Windows". * In the long run, the stuff from "demos" should migrate to "contrib". * "COPYING" should be moved into the various subprojects (if not already there). There is no need to force a single licensing policy on everybody. * Merge "INSTALL" into "README". Is this OK with everybody? Cheers, S.

Next Message by Thread: click to view message preview

Re: Renaming "portable"

Sven -- I agree with all your proposed changes. We should probably set up one or more tags before "pruning" so that if someone comes along and wants the BeOS or Mac OS 8/9 code they can grab it easily, but that's obviously no big deal to arrange... Richard -- Your help is certainly appreciated, and could be well spent on the SI/"portable" code -- it needs to move towards 1.1 compliance, and of course adding solid support for more platforms is a Good Thing as well... Garin