Le 19 mai 09 à 11:30, Fons Adriaensen a écrit : > On Tue, May 19, 2009 at 10:38:24AM +0200, Stéphane Letz wrote: > >> 5) Another idea would be improve the "choice of auto-start >> strategy" by >> providing a runtime choice for that: a way for the user to select >> between >> the "classic", "D-Bus", "OSC", strategy once globally for a given >> working >> session... > > I will be writing an OSC layer (on top of the existing interfaces) > because I badly need a soluting for scriptable (i.e. non-interactive) > remote control of jackd. > > It will be non-invasive and just use the existing jackd/libjack > without modifying anything. There will be no such thing as an > 'OSC autostart strategy'. > > IMHO dbus could be just the same. This would mean that > any advantages it may bring will be there only if app > writers start using it *explicitly* by directly calling > dbus instead of a jackd/libjack C API function. > > Which just means that dbus will have to prove its value > in the market instead of being forced onto everyone, > and that is a Good Thing (TM). > > Support for accessing dbus could even be integrated in > libjack (or some new library) as long as it just adds > ew calls and does not modify the action of any existing > C API call. > > Ciao, > > -- > FA
It seems you really don't want to see that using this "jack_client_open does a fork+exec call to launch jackd with the ./ jackdrc file" has been completely *hard coded* in libjack from day one! And is a really strong constraint for any possible new way of controlling the server. The discussion is now: do we keep this "hard coded thing in libjack" or do we try to relax it a bit ? Stephane _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
