[LAD] LADI

[Paul Davis]

On Fri, Nov 20, 2009 at 10:06 PM, Patrick Shirkey
<pshirkey at boosthardware.com> wrote:

> It's not easy to find motivation for continuing development when a large
> subset of your ideas are received as fundamentally flawed because of the
> core design choice that enables their existence.

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.