Re: [LAD] New proposal for the jackd/jackdbus mess

Le 20 mai 09 à 13:55, Krzysztof Foltman a écrit :

> Stéphane Letz wrote:
>
>> Not really, the existing IPC server/client scheme just need to be
>> extended with new "calls".
>
> Okay.
>
> Then, if you're keeping the "fork and exec" method of starting the
> server, will it in any way be guaranteed than all control clients will
> have the same functionality as the client which initially started  
> jackd?

Why not?
>
> Otherwise, starting a single client will prevent any control  
> application
> started later from being able to do its job.

In what way?

> In non-DBUS JACK the
> application that started jackd had a monopoly on access to its
> stdout/stderr.

Not clear for me.

>
>
> Also, what if the application that did fork and exec crashes?

Same behaviour as now, the server detects crashed client and stops if  
started in "temporary" (-T mode)
or continue to run if started non temporary.

> What if
> the server crashes?

As usual, client can detect that using the "shutdown" callback.

> What if both crash, but other control applications
> are still running?

  "shutdown" callback.

> I think that in any correct solution, the fact that
> an application has started jackd shouldn't give it any more (or less)
> influence on jackd than any other client in the system - otherwise  
> it is
> a race condition. The hypothetical new version of qjackctl should have
> the same feature set no matter if it was started before or after, say,
> Hydrogen.
>
> Can the same IPC protocol you plan to use for the control protocol be
> reused for the out-of-band MIDI SysEx data? (we've been talking about
> that before, and it's really out of scope of control protocol
> discussion, but it might be useful at some point).
>

No idea right now. I think we should focus on the global design.

Stephane

1242821433.28815_0.ltw:2,a <AEDA49B3-E39F-4714-8960-4EA6F1340823 at grame dot fr>