[LAD] [Jack-Devel] New proposal for the jackd/jackdbus mess

[Rui Nuno Capela]

On Wed, May 20, 2009 10:32, Stéphane Letz wrote:
> Hi all,
>
>
> New much simplified proposal, should be "Fons compatible", hopefully
> "Nedko compatible" (with little work), "Paul one package only
> compatible", others "keep it simple compatible"...
>
> 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 conceptual change is that "jackd"
> process is supposed to be an "always running" daemon that defines an IPC
> entry point to be used from "clients". This daemon does not
> "automatically" starts the server (as it does now), but will  when
> requested (either by the "jackd" code directly using C API ) or by the
> request of external control font-end using IPC.
>
>
> 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)
>
>
> - 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. Even if they deal with multiple configs in a new format
> (XML...) they are supposed to always put a "default" state in
> ~/jackdrc for the client "auto-start"  feature to continue working.
>
>
> - Ardour can still do it's server control mess on its own... ((-:
>
>
> 3) General:
>
>
> - a single jack2 package is needed. It contains the "jackd" daemon/
> server are before.
>
> - "jackdbus" is now conceptually separated from the Jack source code.
> It only uses jack.h + control.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.
>
> - old fashion users can keep their habits
>
>
> - new "D-Bus aware" guys can explore new fields...
>
>
> This scheme seems to hopefully solve most of the problems we had, and
> requires only a bit of change for the "jackdbus" front-end to continue
> working, but not much.
>
> Comments?
>

no comments.

Stéphane, you're a champion hero!

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org