[LAD] Keeping "guardians" and "rebels" on the same boat

Hi all,

I would be happy to get some reactions of this proposal that tries to  
keep the "guardians" and the "rebels" on the same boat. The pdf file  
for this proposal is : http://www.grame.fr/~letz/jackcontrol2.pdf.  
Compared to latest Fons proposal, this proposal basically combine the  
"control daemon" and the "jackd" server in a *unique* extended jackd  
(with control API IPC) (see 5). It also tries to minimize the number  
of shared libraries in the system, although we may decide to break-up  
the code in separated libraries if this is really needed (see 3).  
Concerning Torben proposal to have "control plug-ins" be part of the  
server, I agree with Fons here: this would be quite limited and more  
complex:  a new interface would have to be defined, "who" is loading  
those plug-ins in the server... and so on.

Let me explain it again:

The first "big" conceptual change compared to the current SVN state is  
this new "control IPC" scheme. That is the so called control API can  
be used on client side also. The other point is this concept of "multi- 
config share state" (see 3).

1) Server side:

- libjackserver.so contains: server code + C control API  + "new" IPC  
control API (server side) +  C Jack API  + IPC Jack API (server side)

- jackd executable is linked with libjackserver.so  (nothing new here)

- backends (ALSA, dummy...) are linked with libjackserver.so  (nothing  
new here)

- a "standalone" client (that wants to embed the server in it's  
process) is linked with libjackserver.so and directly uses the C  
control API  to control/start the server and C Jack API to be a client  
(nothing new here).


2) Client side:

- libjack.so contains :  "new" IPC control API (client side) + IPC  
Jack API (client side) + config API (TO BE DEFINED)

- clients are linked to libjack.so (nothing new here)

- new control front-end (jackdbus, jackOSC...) are linked to  
libjack.so: they control the server using the IPC control API (client  
side), they can be regular clients using IPC Jack API (client side) to  
deal with connections management and so on...

- a "default" centralized state for the server is always kept in ~/ 
jackdrc. When a client wants to auto-start, this "default" state is  
used. (this is important to keep in mind)

- libjack may have to start the "jackd" executable using the fork+exec  
way, or the "jackd" process is an "always running + relaunch" process  
(this has to be more defined later on...)

- Qjakctl stays as a regular client, it can still start the "jackd"  
process as usual. It can keep its own way of keeping multiple  
configurations as it does now.

- more sophisticated control front-end (jackdbus, jackOSC...) are now  
regular clients. They can use the IPC control API (client side) for  
more sophisticated control of the server. As regular clients, they  
access the API to control connections... and so on. The important  
thing is that those clients are *obliged* to deal with this "default"  
centralized state.


3) Centralized multi-settings share state

- the idea is to provide a way to *share* multiple server  
configurations in a unique place for all control applications. This is  
part the D-Bus proposal in some sense. WE HAVE TO DECIDE IF WE WANT  
THIS FEATURE BE PART OF JACK OR NOT (this can be coded as part of  
libjack.so or in a separated library called "libjackconfig.so" is we  
need to share this code between the sever and client side).

- If we don't share a unique state, then any control application  
(jackdbus or any other in the future) will have the choice to use any  
format (XML...) but then obviously we loose the fact that all control  
applications would always see the same settings.


4) General:

- a single jack2 package is needed. It contains the "jackd" daemon/ 
server as before.

- "jackdbus" is now conceptually separated from the Jack source code.  
It only uses jack.h + control.h + config.h (??) and is linked to  
libjack.so as any regular client. It can be distributed separately as  
a more sophisticated control front-end available, or be available in  
the jack2 package.


5) Points of discussion:

- this model is somewhat simplified compared to the latest Fons  
proposal (a daemon process + [possibly] several separated jackd  
servers). The point is that separated processes for control daemon and  
jackd servers would need another mechanism for "control daemon" <===>   
jackd server communications (that is: the control daemon launches the  
jackd server, but then has to control it while it is running, possibly  
get some info from it (notifications.. etc..)).  If we stay with a  
unique "extended jackd" (with control API IPC), then things are a lot  
simpler. We can consider that having a single running jackd server is  
a common case and having several running jackd server a "corner case".  
It we decide that several running jackd servers is really necessary,  
then the "extended jackd" can still handle the situation if we accept  
to have several jackd servers running in a same process. Otherwise a  
more complex model for "completely separated control daemon and  
several jackd servers" has to be defined.

- multi-config stare state: is this part of Jack or not?

- if  multi-config share state is part of Jack, then a new API to  
handle that has to be defined

- when proposing new things, please keep in mind that jack2 is now  
multi-platform... don't be too Linux focused.

Comments welcome!

Stéphane

1243244566.7768_0.ltw:2,a <3B4E00F6-D181-40AA-95E7-ECBC39DE2DDE at grame dot fr>