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

On Tue, May 19, 2009 09:38, Stéphane Letz wrote:
> Hi All,
>
>
> After hours of discussion on #jack IRC, it seems that we are in a
> completely blocked situation:
>
> 1) we currently have 2 "incarnations" of the jack server named "jackd"
> and "jackdbus". "jackd" is the legacy  "classic" version of the server that
> interact with the ~/jackdrc setting file. This setting file may be written
> by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware version of the
> server, it use a completely new setting management system using a
> "conf.xml" file. Il may use a multi-setting system in
> the future.
>
> 2) the *heart" of the problem Fons initially told about is in the way
> applications "auto-start" the server. This launching strategy is part of
> libjack and depends of the incarnation of the server (jackd of jackdbus)
> that is supposed to be used. Right now this strategy is chosen at *compile
> time*, so that in "classic" mode the "jackd" server will be launched using
> a fork-exec strategy, or in D-Bus mode the "jackdbus" server will be
> launched by issuing a D-Bus call.
>
> 3) Since the "auto-start" strategy is chosen at compile time and thus
> is coded in libjack, users will typically encounter all sort of problems as
> soon as the used applications interact with a "D-Bus based strategy"
> libjack (that will launch "jackdbus" incarnation) and users still use
> Qjackctl that interact with the "jackd" incarnation.
>
>
> 4) Different ideas have been proposed  to merge the 2 "jackd" and
> "jackdbus" incarnations in a unique extended "jackd" exe, but nothing
> really clear emerged.
>
> 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...
>
> 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...
>
> 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.
>
> Comments?
>

(there are two 5)'s above but i'll refer to the first one)

i vote for the 5) auto-start strategy. user selects which one he/she
prefers. the default should be "classic" and i would add fallback to
"d-bus" and/or "osc" whatever. i still fail to see the problem of honoring
.jackdrc if it exists on your home directory. ie. if .jackdrc exists then
do the "classic" auto-start; if not, check d-bus service; etc.

byee
-- 
rncbc aka Rui Nuno Capela
[hidden]

1242725416.6922_0.ltw:2,a <59153.213.58.131.130.1242725389.squirrel at www dot rncbc dot org>