17 May
2009
17 May
'09
9:43 a.m.
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
The only argument pro using dbus I'v heard so far
is that it permits run-time discovery of new backends,
internal clients and their parameters.
That's unfair. Read the archives. There are more arguments to that.
Dbus assumes there is a local login, without that
there is no session bus, and things don't work.
Most of my audio machines are headless, there is
no local login, but I still expect things to work,
and that, IMHO, is not unreasonable.
It is not unreasonable. No one said you *had* to use dbus. This needs
fixing and until it is fixed, packagers should be advised to disable dbus.
If it doesn't add any functionality that can be
provided in simpler ways, and if it doesn't work
in some perfectly legal use cases, there is no
reason for having it.
The code for the legacy behavior might make jack a few lines lighter, but
have you looked at qjackctl's code ? Starting jack via some pseudo command
line scripting using Qt and c++ is not something I'd like to maintain. The
thing is, Rui had no choice since it is the only way one could build a
control application with the legacy jack. That's one of the things a
control API is meant to change.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais