Re: [LAD] [Jack-Devel] more jack/qjackctl madness

"MarcO'Chapeau" <[hidden]> writes:

> On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <[hidden]>
> 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.

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.

>> 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.

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>

1242633961.29058_0.ltw:2,a <87k54ekf9t.fsf at usbix dot spacelabs dot org>