19 May
2009
19 May
'09
10:03 a.m.
On Tuesday 19 May 2009 05:44:13 Stéphane Letz wrote:
Le 19 mai 09 à 11:30, Fons Adriaensen a écrit :
Doesn't my idea of having the new way check for the old way on start and
translate between the two solve this issue? (And write the old way file on
new way changes.
Also wouldn't having a commandline switch:
jackd --way new|old|dbus|osc|classic|whatever
do the job?
(speaking from vast fields of ignorance here I know.)
On Tue, May 19, 2009 at 10:38:24AM +0200,
Stéphane Letz wrote:
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 ? 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
Stephane
all the best,
drew