18 May
2009
18 May
'09
6:05 a.m.
"MarcO'Chapeau" <marco(a)marcochapeau.org> writes:
ATM headless and multiserver setups are not covered by jackdbus. This
*can* be fixed with dbus model.
Packagers tha have made the packages should have read this before
enabling dbus:
http://trac.jackaudio.org/wiki/JackDbusPackaging
Maybe they did. I dont see why you Fons are attacking jackdbus because of
packaging not matching your needs.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen
<fons(a)kokkinizita.net>
wrote:
All features that jackdbus offers can be added without dbus. Using dbus
was and still is the best way. It will be the best until there is better
reusable model invented. Or if someone donates (development time) to
implement such object model. Most important thing missing in jackd is
the log file. Then you have other missing features:
* no way several app to control single jack server. One needs to adopt it.
* no runtime discovery of jack settings
* no hierarchical settings file
* complex patchbay API that results in complicated code in patchbay apps
* multithread (for jack1 realtime too) threading model. (GUI) control
patchbay app should be allowed to be single threaded and not required
to handle graph change events in a realtime context.
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.