24 Jan
2008
24 Jan
'08
7:09 a.m.
On Thu, 2008-01-24 at 10:25 +0000, Krzysztof Foltman wrote:
The issue here is the advancement of Linux Audio in general. Changing
APIs is a short-term issue. IMHO, the long-term benefits of a better
engineered API far outweigh the short-term costs of breaking
compatibility.
Not only that, but the number of applications that support the current
API is very small. And I would indeed personally update the
applications I use. I did it before, LADCCAifying various applications,
from scratch. You may recall that a set of patches were included in
LADCCA releases.
If people wanted to use the current API, they can carry on doing so.
There's no reason they have to update to a newer API; nobody is going to
go into lash-0.5.4.tar.gz on nongnu.org and change the files in it.
Bob
--
Bob Ham <rah(a)bash.sh>
Bob Ham wrote:
No. But I wouldn't try to automate dealing with it, unless it happened
a lot. But then, if it happened a lot, I'd fix the bug instead.
Of course it needs to handle it. It needs to
cleanly shut down due to
the catastrophic failure.
You'd want that during live performance? :) In a debug version, it could be desirable, but for
"production" use
(sorry for webspeak) it is unacceptable. It should be as fault-tolerant
as possible in those situations.
Yes, you're right, JACK should be as fault tolerant as possible :-)
I think
it's important *to* break the current API due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
LASH adoption was slow enough to start with. Several projects exist that
use current LASH, some are quite useful (Hydrogen, Specimen), do you
want to personally update each and every of those