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

On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz <[hidden]> wrote:
> 4) A possible proposed solution was to define 2 completely separated  
> packages for jack2 : the "classic" one would package the "jackd"  
> incarnation and allow Qjackctl and legacy control applications to be  
> used with it. The "D-Bus" one would package the "jackdbus"  
> incarnation, and provide D-Bus bas control applications (patchage,  
> ladi tools....). The problem of this strategy is that..., it is a kind  
> of complete failure regarding the way jack is supposed to be  
> distributed. It may even get worse if a new "jackosc" incarnation (a  
> one that would allow to control the server using OSC) appears a some  
> point in the future...

And we will all agree that this would be a packaging disaster. I package
jack for gentoo pro-audio, and I really don't know how I'd handle this one.

> 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...

To me, this one is the cleanest of all, and would allow to keep auto-start
for those who like it with the flavor of their choice (and eventually
disable it for those who don't ?)

> 5) Another idea would be be to completely drops the "auto-start"  
> strategy...This way we don't have multiple strategy anymore, and solve  
> most of the problems... but loose a feature.

Last resort but if it comes down to this, I can handle my idea of
auto-start directly inside LADITools using dbus calls. although it wouldn't
be as good as the "any client can auto-start jack" paradigm.

Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais

1242726442.8586_0.ltw:2,a <aa6ebf92439e5b4731462b7049a0a701 at localhost>