|
»
« Return to Thread: A picture...of the global mess
Re: A picture...of the global mess
by torbenh
::
Rate this Message:
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.
>
> Does it helps?
>
> Stephane
>
>
>
> _______________________________________________
> 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
> 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.
>
> Does it helps?
>
> Stephane
>
>
>
> _______________________________________________
> 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: A picture...of the global mess
| Free embeddable forum powered by Nabble | Forum Help |
