Server control plug-ins proposal

Hi all,

Here is a patch that implements "Server control plug-ins" in JACK2  
SVN. The idea is to appease the DBus "guardians/rebels" war by cleanly  
separating the DBus code from the JACK2 code base. The proposed model  
hopefully helps without doing to much deep changes in the server code:

- a "control plug-in" is loaded in the server process, uses the  
Control API to control the server and possibly expose this API to  
external process using it's chosen IPC model.

- control plug-ins are named "jack_control_XXX" and are placed in the  
standard /usr/lib/jack folder where backends and internal clients are  
already placed.

- when the "jackd" process starts, it uses the parameters as usual,  
starts the server with the given parameters, but also scans in the /
usr/lib/jack folder, and loads and activates all available control  
plug-ins.

- if "jackd" is started without any parameter, then it just loads and  
activates all available control plug-ins  (see later).

- the "jackdbus" exe has been removed (see later).

Right now two plug-ins have been developed:

- on OSX, the "jack_control_osx"  plug-in notify others process when  
the JACK server starts and stops (using OSX specific IPC). This allows  
to remove long standing OSX specific code from the jackdmp.cpp file  
(that one that implements "jackd" exe). Nedko should be happy now.

- the "jack_control_dbus"  plug-in is the "jackbus.c" code reworked a  
bit to be used as a plug-in. The DBus dependancy that was done in  
libjack (when compiled in DBus mode) has been removed. Now an auto-
starting client launches "jackd" (possibly with parameters  
from .jackdrc) as it was before. The DBus service that was described  
in "org.jackaudio.service" file is no more "jackdbus", but simply  
"jackd".


To test:
======

./waf configure --dbus --classic, on OSX both jack_control_osx" and  
"jack_control_dbus" are compiled, on Linux only  "jack_control_dbus"  
is compiled.

When starting "jack" (either in a terminal or using Qjackctl) the  
"jack_control_dbus" control plug-in will be activated. The python  
"jack_control" will see the running "jackd" and allow to control it.  
If a DBus application is started first, then it will activate the  
"org.jackaudio.service" service that will simply launch "jackd"  
without parameters.


Knows problems, limitations:
=======================

- since the DBus code (now in "jack_control_dbus") uses it's own  
server setting format (XML file), they are still state coherency  
issues between the state kept in this XML file and the state used by  
the running server. A possible solution would be for the  
"jack_control_dbus" plug-in to get the state from the running server  
and save it in it's own format. But Nedko can comment more on that  
specific point.

- all loaded control plug-ins will get a pointer on the running server  
in their initialize function. So all control plug-ins see and control  
the *same* unique server. There is no "coherency" control between what  
each plug-in does on the server. (The model is kept simple for now...)

- they are probably still some bugs...

Future:
=======

- this model can be extended quite naturally if we finally decide to  
also have the control API available on client side (available using  
libjack.so). We would need to develop a "jack_control_ipc" kind of  
plug-in to expose this API on client side by extending current server/
client IPC.

Comments, suggestions, improvements welcome!

Stéphane

Patch : http:www.grame.fr/~letz/controlplug.patch

New global model : http:www.grame.fr/~letz/jackcontrol4.pdf
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org