Re: [LAD] New proposal for the jackd/jackdbus mess

Stéphane Letz wrote:

> Not really, the existing IPC server/client scheme just need to be
> extended with new "calls".

Okay.

Then, if you're keeping the "fork and exec" method of starting the
server, will it in any way be guaranteed than all control clients will
have the same functionality as the client which initially started jackd?
Otherwise, starting a single client will prevent any control application
started later from being able to do its job. In non-DBUS JACK the
application that started jackd had a monopoly on access to its
stdout/stderr.

Also, what if the application that did fork and exec crashes? What if
the server crashes? What if both crash, but other control applications
are still running? I think that in any correct solution, the fact that
an application has started jackd shouldn't give it any more (or less)
influence on jackd than any other client in the system - otherwise it is
a race condition. The hypothetical new version of qjackctl should have
the same feature set no matter if it was started before or after, say,
Hydrogen.

Can the same IPC protocol you plan to use for the control protocol be
reused for the out-of-band MIDI SysEx data? (we've been talking about
that before, and it's really out of scope of control protocol
discussion, but it might be useful at some point).

Krzysztof

1242820547.26285_0.ltw:2,a <4A13EFB7.5070401 at foltman dot com>