On Thu, 24 Oct 2002, Matt Flax wrote: > One of the more beautiful things about ALSA is the fact that it is not > ready to settle ... it is progressive ... that in my opinion is why the > API changes, along with other things like module names, etc. > I'm sure though that it will and is mature enough to start settling > naturally ....
And, really, if you look at kernel development, this a very good way to do development - not just while closing in on 1.0. If we continue comparing to the kernel, biggest problem with ALSA has been the 'app-developers <-> ALSA' interface. While glibc has been the stable wrapper for linux, alsa-lib's public API has been changing as much as the internals - if not even more. ;) But of course, this comparison isn't really fair as glibc mostly implements existing standard interfaces (POSIX, XOPEN), while ALSA's APIs are new ones. Anyway, my main point is that these two sides of ALSA (the alsa-lib public API, and the rest), should be discussed separately. For the former, changes are highly undesirable, while for the latter, continuous progress is the only way to go. PS Btw; nothing stops from developing new, better public interfaces for alsa-lib after 0.9 and 1.0, but these should be developed as alternatives, not breaking the old API. -- http://www.eca.cx Audio software for Linux! ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel