[LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

[Stéphane Letz]

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