|
»
« Return to Thread: Server control plug-ins proposal
Re: Server control plug-ins proposal
by torbenh
::
Rate this Message:
On Wed, Jun 03, 2009 at 05:03:15PM +0200, Stéphane Letz wrote:
> 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.
hmm... you load the control plugins after server start.
is that necessary ?
if they were loaded earlier, they could even change some configuration
values. but this would of course open the issue of fighting plugins.
maybe its a can of worms you dont want to open ?
hmm... it seems i am overlooking something here.
maybe jack_controller_settings_init() is doing something similar.
i dont completely see how the config functionality of the old dbus
implementation is working now.
>
> - 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".
>
> 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.
if we find out how to prevent plugin config fighting, the plugin could
configure the server_ctl before its started.
is the libjackconfig idea still in discussion ?
>
> - 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...)
i think a single lock for the whole control API and control plugins
"playing nice" should be enough.
some sort of callback or callbacks, when server state is changed, should
be enough, to make it possible, for many plugins to control a single
server.
multiple plugins
is a cornercase we should not put too much energy into (iE no fine
grained locking and multiple callbacks.)
maybe even an rw lock on the control API ? release of w lock triggers
callback. and plugins know something changed.
>
> - 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
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> 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.
hmm... you load the control plugins after server start.
is that necessary ?
if they were loaded earlier, they could even change some configuration
values. but this would of course open the issue of fighting plugins.
maybe its a can of worms you dont want to open ?
hmm... it seems i am overlooking something here.
maybe jack_controller_settings_init() is doing something similar.
i dont completely see how the config functionality of the old dbus
implementation is working now.
>
> - 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".
>
> 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.
if we find out how to prevent plugin config fighting, the plugin could
configure the server_ctl before its started.
is the libjackconfig idea still in discussion ?
>
> - 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...)
i think a single lock for the whole control API and control plugins
"playing nice" should be enough.
some sort of callback or callbacks, when server state is changed, should
be enough, to make it possible, for many plugins to control a single
server.
multiple plugins
is a cornercase we should not put too much energy into (iE no fine
grained locking and multiple callbacks.)
maybe even an rw lock on the control API ? release of w lock triggers
callback. and plugins know something changed.
>
> - 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
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
« Return to Thread: Server control plug-ins proposal
| Free embeddable forum powered by Nabble | Forum Help |
