Status of server control plug-ins branch

View: New views
1 Messages — Rating Filter:   Alert me  

Status of server control plug-ins branch

by Stéphane Letz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi all,

There is a git branch to be tested for "server control plug-ins" idea:

http://repo.or.cz/w/jack2.git?a=shortlog;h=refs/heads/controlplugin

To summarize what is implemented:

- 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 processes using it's chosen IPC model.

They are 2 model of control plug-ins:

- 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. Those plug-ins are loaded explicitly using a new -C  
parameter in jackd parameters.

-  "auto-loadable"  control plug-ins are named "jack_control_auto_XXX"  
and are placed in the standard /usr/lib/jack folder where backends and  
internal clients are already placed. Those plug-ins are always loaded.

- control plugins can implement a "jackctl_plugin_autostart" function,  
to be used when JACK client want to autostart.

- when the "jackd" process starts, it uses the parameters as usual. If  
-C "jack_control_XXX"  is used, the corresponding plugin is loaded and  
initialized.

- if "jack -C jack_control_XXX" is used, then the process starts, the  
corresponding plugin is loaded and initialized, the jacks server is  
*not* started  (that is the control plugin is waiting for commands  
using its own IPC to control the server)

- on OSX, the "jack_control_auto_osx"   "auto-loadable"  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.

DBus control as a control plugin
==========================

- the  "jackdbus" exe has been removed and is replaced by  a  
"jack_control_dbus" plugin. The DBus service now execute the "jackd -C  
dbus" command. This plugin implements an "jackctl_plugin_autostart"  
function to be used to start jackd server using DBus for auto starting  
clients.


To test:
======

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

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.

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.

- the DBus code is no more using internal JACK code. It only uses  
public headers and links to "libjackserver.so". So we can possibly  
separate DBus control as a separated package (and that would be  
probably a good thing). The idea is that "guardians" would only  
install the JACK2 package and have the old way of interacting with the  
server, and "rebels" would install a separated "JACK2 Dbus  
control" (or something) additional package and use DBus based control  
tools.

Please test and report!

Comments, suggestions, improvements welcome!

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org