Fons Adriaensen wrote:
> There is IMHO *no* reason why jack-dbus should
> **intercept** C API calls, start its daemon,
> and take control.
Hmm?
libjack from non-DBUS package detects if JACK server is running, if not,
it starts the server by doing fork&exec.
libjack from DBUS package detects if JACK server is running, if not, it
starts the server by telling DBUS server to do fork&exec.
I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or
eating babies.
It may be harder to notice that the libjack-using application has just
started the JACK server because the server's output goes to a log file
and not stdout, but some people actually like it that way (especially
when used with tools like laditray).
I'm not saying DBUS version should be used by everyone, or that the
currently available set of tools can be safely used by general public.
On the other hand, I'm not buying into any anti-DBUS hysteria, because
the "JACK server as a background service and not stdout-spamming
application forked out from random client process" makes a lot of sense
to me.
Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue May 19 04:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 04:15:02 EEST