Re: [LAD] LADI

On Fri, Nov 20, 2009 at 10:06 PM, Patrick Shirkey <pshirkey(a)boosthardware.com> wrote: I think that I should be clear on why nedko's work on using dbus with jack has not been integrated into the jack1 codebase. Its really very simple, and has absolutely to do with the "dbus" issue in the way that it has played out on this mailing list. there are basically a few core reasons: 1) the coding guidelines specify that the core jack1 codebase should contain only ANSI C and POSIX. we allow utility clients to exist that have other dependencies, but they are always conditionally compiled and are not considered core elements of JACK. dbus does not meet this test. 2) the only API to talk to the JACK server has been provided by one or more libraries provided by JACK. this means, for example, that we have not "published" the protocol used between the server and libjack. It is therefore incongruous with the existing design of JACK to add any IPC mechanism (OSC, dbus, CORBA, DCOP, Sun-RPC or whatever else you might care to suggest) directly into the JACK server or libraries that make up the core of JACK. 3) reliance on 3rd party technology is only acceptable if it is clearly platform independent. dbus does not meet this test (although it is not terribly far from meeting it, it still does not meet it). there are actually very few IPC technologies that do. 4) reliance on technologies that appear to be tied into desktop-centric computing architectures should probably be avoided in the core of JACK. Having other JACK tools that integrate well with various desktop platforms seems VERY desirable, but it seems reasonably clear that there is no inherent reason to build such functionality into anything that is distributed as "part of JACK". if a particular distribution wanted to "fix JACK" by integrating into their desktop, that also seems entirely reasonable, and might be something that other distributions would pick up. the success of such work would have little to no impact on the core of JACK. Hopefully, this can remain focused on providing, as well as it can, a cross-platform pro-audio/music audio server for use on a variety of platforms and a variety of use cases, including but not limited to systems where "integration" is not an issue. Nedko's jackdbus actually shows a way to do this: he provides (almost simultaneous) releases of jackbus that feature a level of integration between JACK and dbus-based IPC for control that seems inappropriate for a general release of JACK. I am glad that those who which to control JACK in this way have the chance to do so with current versions - its a good thing. What would always have been acceptable, and without any argument or even much discussion was (a) implementation of the "control API" as a JACK library combined with (b) a client that understand dbus (or OSC, or Sun-RPC or DCOP or whatever) and translated between the JACK control API and whatever protocol it used to communicate with the outside world. Nedko did not want to do things in this way, and has even stated to me on IRC that he believes that we/I should have been willing to simply adopt the work that he did do until something better came along. This is not how Linus has successfully managed the kernel, and although I believe that Linus has done a better job of that then we have managed with JACK, his example is still something that I believe is correct to follow here. Precisely the same points would have had to be made had Nedko or someone else taken a similar approach using OSC, Sun-RPC, DCOP or any other IPC protocol/technology. None of this is intended to negate the entirely valid points that Nedko makes about some aspects of JACK's implemenation(s). However, his sensitivity to people's commentary on dbus, along with some of the really undeserved and ignorant criticism of dbus that has appeared on this mailing list, makes it necessary to try to be as clear as possible on the actual issues that block adoption of some or all of the work he has done. The problems that he has mentioned separately DO need working on (and preferably fixing), and any ideas, designs and contributions of code that meet the coding guidelines long established, along with some of the points I have raised above will be very welcome. Moving on a bit .... I am personally appalled by the debacle that LASH turned into. Stemming from a proposal made years ago (by Bob Ham, I believe), LASH has gone more or less nowhere. It has never arrived at a stable, congruent and consistent specification, even via a header file. The people working on the project have appeared to a casual observer like myself to be in constant turnover and/or constantly redesigning the entire system with a claim that this time it will be done right. The project is, quite frankly, a joke when compared to what has been managed with ALSA, LADSPA, JACK and even something like DSSI. Certainly session management is an important issue when using a weakly connected set of cooperating applications, and it remains almost entirely unsolved. I personally have no faith that any of the work on LASH has moved us notably closer to an actual solution to this issue, although I will grant that it has helped some developers to get a better grasp on what some of the issues actually are, and for that I suppose we must be grateful.