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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
