Re: Server control plug-ins proposal

> 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 ?

>
>>
>> - 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.
>
>