On Thu, 2008-01-24 at 10:25 +0000, Krzysztof Foltman wrote: > Bob Ham wrote: > > > 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? :)
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. > 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 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 <[EMAIL PROTECTED]> _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
