Re: DBus server control : description of 2 proposals

> Up to now, we have 2 proposals for the DBus based JACK server control.
> Please contribute to any points if you think something is missing or
> incorrect.
>
> Thanks.
>
> The 2 proposal (especially the second) may still have implementation
> issues, but I hope they are advanced enough for some comparison to take
> place.
>
> Stephane
>
> ----------------------------------------------------------------
>
> Proposal 1 (Nedko):
>
> 1) a new incarnation of JACK server is called "jackdbus" : this new exe
> in controlable from others processes using the so called control API
> exposed using DBus IPC. A simple python "jack_control" is given as a way
> to control the JACK server. Others tools are "LADI tools" and LASH.
>
> 2) DBus code that was used to cleanly interact with PulseAudio (audio
> card acquire/release scheme) can (has) be moved in jackdbus code.
>
> 3) the jackdbus code interact with JACK using pure public JACK headers
> and linking to the server side library called "libjackserver.so". Il is
> right now in the JACK2 source tree but could be technically separated
> (It somewhat has the same status of any code that use JACK API (server
> or client side) using public JACK headers and linking libraries).
>
> 4) jackdbus uses its own XML based system to save/restore JACK server
> state (JACK server parameters, chosen backend, parameters of the
> backend...). Thus the ~/.jackdrc state is not used anymore.
>
> 5) clients that want to autostart have to control the JACK server using
> the DBus based controler. Thus the old fork+exec model to start the JACK
> server from libjack.so cannot be used anymore.  The latest proposal is
> to use a command like "dbus-send --session --print-reply=yes
> --dest=org.jackaudio.service /org/jackaudio/Controller
> org.jackaudio.JackControl.StartServer" in ~/.jackdrc to start the JACK
> server with the help of DBus based controler. A request is done to keep
> compiled time option to be able to have DBus controler accessed directly
> in libjack.so.
>
> 6) mixing legacy "jackd" incarnation of JACK server with "jackdbus" in
> the receipe for problems. Indeed depending of which controler tool is
> used to start the JACK server (that is legacy Qjackctl controler or new
> "jack_control" or similar), the "jackd" or "jackdbus" incarnation of the
> JACK server will be started. Consequently the server starting state will
> be one that each server incarnation is used.
>
> 7) because of potential problems in the combined use of "jackd" and
> "jackdbus", a fined-grained packaging strategy has to be defined to
> avoid installing "jackd" and "jackdbus" at the same time. Controler
> tools (legacy Qjackctl) or DBus based one have to be installed and their
> dependency controled depending of the installed JACK server incarnation.
> This strategy is explained here :
> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>
> 8) developing others incarnation of JACK server, like "jackOSC" (to be
> controled using OSC) would probably require the same kind of packaging
> strategy.
>
>
> ----------------------------------------------------------------
>
>
> Proposal 2 (Stephane):
>
> 1) a unique "jackd" incarnation of JACK server stays. A new "control
> plugin" scheme is added. A control plugin goal is to expose the so
> called control API using a given IPC model. Two different model of
> control plugin are currently defined: those named "jack_control_auto_XX"
> are automatically loaded by the jackd process. Those named
> "jack_control_XX" are to be loaded on request using a new "-C" parameter
> in jackd command line.
>
> 2)  jackdbus code from proposal 1 has been refactored in a "dbusplugin"
> file to be compiled in the "jack_control_dbus" plugin. This plugin
> expose the control API using DBus IPC and contains the code to cleanly
> interact with PulseAudio (audio car acquire/release scheme). A simple
> python "jack_control" is given as a way to control the JACK server.
> Others tools are "LADI tools" and LASH.
>
> 3) the "dbusplugin" code interacts with JACK using pure public JACK
> headers and linking to the server side library called
> "libjackserver.so". Il is right now in the JACK2 source tree but could
> be technically separated (It somewhat has the same status of any code
> that use JACK API (server or client side) using public JACK headers and
> linking libraries).
>
> 4) jackd process can still be used the legacy way and using the new -C
> parameter to load a control plugin. Thus for instance "jackd -C dbus -R
> -d alsa -p 512" can be used.
>
> 5) JACK DBus service does now "jackd -C dbus" to start the server and
> load the dbus plugin. Then actual control of the server is done through
> DBus IPC.
>
> 4) for clients autostart feature, control plugin can define a
> "jackctl_plugin_server_autostart" to be used in libjack.so JACK server
> starting code. If several installed control plugin have the  
> "jackctl_plugin_server_autostart" , then one of them will be used
> (typically the first found one) . Thus having several installed control
> plugin with the autostart feature is potentially problematic.
>
> 5) the proposed packages scheme is the following:
>    
>     - a standard JACK2 package is defined; is contains "jackd,
> libjack.so, libjackserver.so headers, tools.... It is the exact same
> packaging as legacy JACK. It is then  supposed to be used with legacy
> controler like Qjackctl
>
>     - an additional package contains "jackd_control_dbus.so" and
> "jack_control" DBus based controler to be installed on top of standard
> package. It is then supposed to be used with new DBus based controlers.
>
> 6) other control IPC would typically be implemented in additional
> control plugins: like jack_control_osc" for an OSC based controler. As
> explained in 4), if several controler are installed at the same time
> over a  standard JACK2 package, then the "autostart" behaviour is not
> clearly defined.
>
>
> Stephane_______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>