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

PrevNext  Index
DateTue, 19 May 2009 12:29:12 +0300
From Sampo Savolainen <[hidden] at iki dot fi>
ToFons Adriaensen <[hidden] at kokkinizita dot net>
CcNedko Arnaudov <[hidden] at arnaudov dot name>, Linux Audio Developers <[hidden] at lists dot linuxaudio dot org>, JACK Developers <[hidden] at jackaudio dot org>
In-Reply-ToFons Adriaensen Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Follow-UpStéphane Letz Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Quoting "Fons Adriaensen" <[hidden]>:

> I would have no objection if you added e.g.
>
>    jack_client_open_via_dbus()

How is the application supposed to know whether the user wants to use  
dbus or not?

> leaving the original call as it is.

I agree with Stephanes' 5):

An implementation where dbus and "classic" coexist in a single build  
is the only way to go. The user environment would somehow tell jack  
whether the user wants to use dbus or not. (In fact, I'd argue this  
path should've been chosen from the start.)

Say for example "the file ~/.jack-classic exists" or "environment  
variable JACK_COMMUNICATION=DBUS". Or a system wide configuration:  
"/etc/jackd/configuration says OSC is enabled".

I agree with Nedko that this is not a change in the API. This is a  
change in the implementation of the API. There's a huge difference as  
we all know. We would run into all kinds of trouble if we would make  
client software responsible for choosing the server communication  
model. Hence the implementation was changed, not the API...


Is there anything really difficult here? Just make everyone live  
happily together.


  Sampo
PrevNext  Index

1242725381.6845_0.ltw:2,a <20090519122912.174951k9m4sxxomg at webmail dot helsinki dot fi>