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

-----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@email-addr-hidden
> 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-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon May 25 20:15:01 2009