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

[Christian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stéphane Letz schrieb:
> 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
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> 
> 

Not that much related, but as I'm reading this comes to my mind:
For this app you need jackOSC, for that app you need jackDBUS, for the
other app you need jack* ....
I hope these control-applications will be compatible with each other and
don't interfere.
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoauUwACgkQVC26eJ+o0+3L7ACeMXXIoNMkQX0rKy5xMbVIckwp
k98AnjvyT7i7Uzlu5BdY+1E1XCq61lyY
=3tI2
-----END PGP SIGNATURE-----