Re: A picture...of the global mess

> On Tue, May 19, 2009 at 04:23:30PM +0200, Stéphane Letz wrote:
>> He all,
>>
>> A picture to try  summary what I understand about we would like :
>>
>> - a new shared library called "libjackontrol.so" : is does  
>> implement the so
>> called control API and a IPC mechanism to use it.
>>
>> -  "jackcontrol" is an *always" running deamon that defined an  
>> entry IPC
>> point.  jackcontrol get requests from control applications.  
>> "jackcontrol"
>> can start a seprated server called "jackserver (using a fork+exec)  
>> way.
>> "jackcontrol" is a *unique* place where setting are handled.
>>
>> - "jackd" is a recoded  control application that parse it's command  
>> line,
>> and use the control IPC to speak to "jackcontrol" (then just quits).
>> jackcontrol then start the "jackserver" whith the appropriate  
>> paramaters.
>>
>> - "jackddbus" is a D-Bus aware control application; It receive DBus
>> requests and translate them to control IPC to speak to "jackcontrol".
>> jackcontrol then start the "jackserver" whith the appropriate  
>> paramaters
>>
>> - "libjack.so" speaks also to "jackcontrol" using the control IPC: an
>> client that auto-start actually use this mecanism
>
> i think i have identified the root cuase of the problems.
> the dbus API is exposing a set of factories, which can instantiate the
> server. this server is instantiated by a call to activate, and the
> running server is the SAME object as its factory, accesible through a
> different interface.
>
> this approach is totally flawed, in my opinion.
> it requires the server object to reside in the singleton executable,  
> and
> not in the server itself.
>
> also by tieing a server instance to its dbus factory the model does  
> not
> allow for other "factories" like starting jackd with commandline
> arguments.
>
> the net result is that you are building a huge overengeneered stuff,  
> to
> be able to cope with this flawed model.
>
> i propose: server (instance) and config (factory) are 2 different
> objects. they both have config interface. (server will have a lot of
> read-only attributes) and the config will have also factory inteface.
>
> the configs reside in the singleton, and the server interface  
> resides in
> the server itself. when a server instance is run, it will register
> itself with the singleton so that the singleton knows which servers  
> are
> running.
>
> the server interface is exposed via dbus and the control api.
> iE by making the dbus interface an internal client, and the control  
> API
> is already there anyways (lets consider jack_load and jack_unload and
> set_buffersize this api)
>
> what is missing is the code for the singleton exposing the config api.
> i need to think a bit more, if the server registry isnt enough of an
> enumerator already.
>
> we really only need some api to handle a set of configs. and then  
> decide
> if its a daemon or can be put into libjackconfig.so and be a singleton
> by using file locking.
>
> by just fixing the object model, this all gets so simple its  
> reticulous,
> you guys wrote so many mails about it. and dbus can exist just in
> parallel. making fons happy too :D
>
> the rc started deamon will create a problem in the dbus space, because
> it must reside on the system bus, or the dbus thing will be another
> deamon wrapping another daemon which is bullshit imo.
>
>