A picture...of the global mess

[Stéphane Letz]

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

Does it helps?

Stephane






_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 19 mai 09 à 16:32, Krzysztof Foltman a écrit :

> Stéphane Letz wrote:
>
>> - "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.
>
>> Does it helps?
>
> And how does jackcontrol communicate with jackserver?
>
> ... over DBUS? *ducks*
>
> Krzysztof

Well over an IPC (not Dbus)

Note that we may remove the "jackcontrol + jackserver" separation by  
starting the server inside jackcontrol process. But then if the server  
crash, jackcontrlol is dead. This may be solved by an "jackcontrol  
deamon" automatic relaunch feature...

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

> 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
>
> Does it helps?
>
> Stephane

As alternative diagram we already have the old one:

http://www.marcochapeau.org/documentation/jackenv

Instead of three IPC layers between pyjack(laditools now), you have only
one. I like the architecture described in this diagram.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, May 19, 2009 at 04:49:07PM +0200, Stéphane Letz wrote:

> Note that we may remove the "jackcontrol + jackserver" separation by
> starting the server inside jackcontrol process. But then if the server
> crash, jackcontrlol is dead. This may be solved by an "jackcontrol deamon"
> automatic relaunch feature...

Having a permanent jackd - a real daemon started as a
service by the runlevel scripts - is the solution I'd
prefer.

You talk to it via libjack using the mechanisms already
present in jack - sockets and shared memory. It is this
jackd that will start a server, either requested explicitly
by a control client, or as the result of a jack client
using jack_client_open() to a nonexistant server. The
latter is detected by jackd via the normal libjack
paths.

Servers should probably be separate processes (so they
can be owned by a user).

For those that want it this jackd can have a dbus control
client, which could also be a daemon but this time started
probably from the login scripts.

What is gained is that there is ***no dbus inside jack***
It is this idea of using dbus for internal communication
that I find utterly revolting. It creates a dependency
on dbus (which is unnecessary) and on a session login
(which is limiting its use), and it opens the gates for
all sorts of sick desktop-zealot inspired persistence
and stability risks.

It's also just bad design, comparable to using a $3000
precision programmable voltage source in a circuit where
a 10 cent zener diode would do. Or replacing a fixed
cable by a switch matrix. Or talking to your wife via
a lawyer.

Ciao,


--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

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

[Stéphane Letz]

Le 20 mai 09 à 14:22, torbenh@... a écrit :

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

Sorry by this is already an obsolete proposal. We are now on the "New  
proposal for the jackd/jackdbus mess" thread.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, May 19, 2009 at 04:23:30PM +0200, Stéphane Letz wrote:
> A picture to try  summary what I understand about we would like :
>

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

You don't need this jackd. If all the IPC is in libjack, an
autostart request can be passed directly to jackcontrol without
creating a transient process.

1. Client uses jack_client_open() with autostart.
2. Libjack doesn't find the server
3. Libjack sends 'start server' to jackcontrol
4. jackcontrol starts the server
5. jackcontrol notifies libjack
6. The jack_client_open() call proceeds.

Between 3 and 5 the thread doing the original call
(i.e. the client's thread) just waits within libjack
for the ok/fail message from jackcontrol.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jack O'Quin]

On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen <fons@...> wrote:

> On Tue, May 19, 2009 at 04:23:30PM +0200, Stéphane Letz wrote:
>> A picture to try  summary what I understand about we would like :
>>
>
>> -  "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.
>
> You don't need this jackd. If all the IPC is in libjack, an
> autostart request can be passed directly to jackcontrol without
> creating a transient process.
>
> 1. Client uses jack_client_open() with autostart.
> 2. Libjack doesn't find the server
> 3. Libjack sends 'start server' to jackcontrol
> 4. jackcontrol starts the server
> 5. jackcontrol notifies libjack
> 6. The jack_client_open() call proceeds.
>
> Between 3 and 5 the thread doing the original call
> (i.e. the client's thread) just waits within libjack
> for the ok/fail message from jackcontrol.

Don't forget a timeout in case the fork/exec fails and there is no message.
--
 joq
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Wed, May 20, 2009 at 04:43:33PM -0500, Jack O'Quin wrote:

> On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen <fons@...> wrote:
>
> > You don't need this jackd. If all the IPC is in libjack, an
> > autostart request can be passed directly to jackcontrol without
> > creating a transient process.
> >
> > 1. Client uses jack_client_open() with autostart.
> > 2. Libjack doesn't find the server
> > 3. Libjack sends 'start server' to jackcontrol
> > 4. jackcontrol starts the server
> > 5. jackcontrol notifies libjack
> > 6. The jack_client_open() call proceeds.
> >
> > Between 3 and 5 the thread doing the original call
> > (i.e. the client's thread) just waits within libjack
> > for the ok/fail message from jackcontrol.
>
> Don't forget a timeout in case the fork/exec fails and there is no message.

The fork/exec is done by jackcontrol, if it fails then
jackcontrol reports this and the entire jack_client_open()
is made to fail. A timeout is required to cover the case
that jackcontrol isn't there (but that can be tested before
the start server request), or it crashes doing the fork/exec,
but in the latter case there are bigger problems anyway.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Wed, May 20, 2009 at 02:22:47PM +0200, torbenh@... wrote:

> 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 alternative to this is that the singleton is made to be
the only entity that can create a server, then it knows about
all of them anyway. As far as I've understood this is what is
currently planned.

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

No, that daemon doesn't have to include anything dbus.
A session-dbus client can attach to it when it gets created,
as could any other. The daemon has 'clients', just as a
jack server has, the session-dbus one is just one possible
client.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jack O'Quin]

On Wed, May 20, 2009 at 04:43:33PM -0500, Jack O'Quin wrote:
> Don't forget a timeout in case the fork/exec fails and there is no message.

>> On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen <fons@...> wrote:
>
> The fork/exec is done by jackcontrol, if it fails then
> jackcontrol reports this and the entire jack_client_open()
> is made to fail.

Yes, that's the way one would like it to work.  But the real situation
is a bit more complicated (see the start_server function in
libjack/client.c).

First, note that since exec() is called in the child process, there is
no failure code returned in the parent (i.e. client) process address
space.  Second, there are actually two fork() calls.  That ensures
that any zombie proc structure created on exit from jackd will
automatically be cleaned up by the init process.  That avoids
depending on the client to call wait(), which it would not know it
needed to do.
--
 joq
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fernando Lopez-Lezcano]

On Tue, 2009-05-19 at 21:39 +0200, Fons Adriaensen wrote:

> On Tue, May 19, 2009 at 04:49:07PM +0200, Stéphane Letz wrote:
>
> > Note that we may remove the "jackcontrol + jackserver" separation by
> > starting the server inside jackcontrol process. But then if the server
> > crash, jackcontrlol is dead. This may be solved by an "jackcontrol deamon"
> > automatic relaunch feature...
>
> Having a permanent jackd - a real daemon started as a
> service by the runlevel scripts - is the solution I'd
> prefer.

I would agree (sorry for the late response). Dbus _is_ actually a
server, and an external one that does not have anything to do with jack.
It is just convenient, but the assumption that it will always be there
is flawed.

-- Fernando

> You talk to it via libjack using the mechanisms already
> present in jack - sockets and shared memory. It is this
> jackd that will start a server, either requested explicitly
> by a control client, or as the result of a jack client
> using jack_client_open() to a nonexistant server. The
> latter is detected by jackd via the normal libjack
> paths.
>
> Servers should probably be separate processes (so they
> can be owned by a user).
>
> For those that want it this jackd can have a dbus control
> client, which could also be a daemon but this time started
> probably from the login scripts.
>
> What is gained is that there is ***no dbus inside jack***
> It is this idea of using dbus for internal communication
> that I find utterly revolting. It creates a dependency
> on dbus (which is unnecessary) and on a session login
> (which is limiting its use), and it opens the gates for
> all sorts of sick desktop-zealot inspired persistence
> and stability risks.
>
> It's also just bad design, comparable to using a $3000
> precision programmable voltage source in a circuit where
> a 10 cent zener diode would do. Or replacing a fixed
> cable by a switch matrix. Or talking to your wife via
> a lawyer.
>
> Ciao,
>
>

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org