Re: DBus server control : description of 2 proposals

Stéphane, thanks for your summary.

> Proposal 1 (Nedko):

Correct

> Proposal 2 (Stephane):
>
> 1) a unique "jackd" incarnation of JACK server stays. A new "control
> plugin" scheme is added. A control plugin goal is to expose the so
> called control API using a given IPC model. Two different model of
> control plugin are currently defined: those named
> "jack_control_auto_XX" are automatically loaded by the jackd process.
> Those named "jack_control_XX" are to be loaded on request using a new
> "-C" parameter in jackd command line.

I still dont see how "jackd -C dbus" is better than jackdbus. Both
present persistent endpoint and former is even worse because it pushes
new infrastructure semantics into jackd thus causing more confusion.

> 4) jackd process can still be used the legacy way and using the new -C
> parameter to load a control plugin. Thus for instance "jackd -C dbus -
> R -d alsa -p 512" can be used.

I don't see how this is the legacy way. It presents persistent endpoint
semantics, right?

IMHO whether dbus is used or not is not the definition of legacy
way. The definition is whether it follows the legacy semantics. Legacy
semantics mean that if you have jackd process running then the server is
started. (this paragraph is not an argument against 4) above but
clarification for readers of thsi thread).

> 4) for clients autostart feature, control plugin can define a
> "jackctl_plugin_server_autostart" to be used in libjack.so JACK server
> starting code. If several installed control plugin have the
> "jackctl_plugin_server_autostart" , then one of them will be used
> (typically the first found one) . Thus having several installed
> control plugin with the autostart feature is potentially problematic.

Indeed. Moreover, the issues that arise from "classic" plugin (default?)
and "dbus" plugin both installed are same as with my proposal. Am I
right?
This is in no way different from
http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

In both cases you have dbus stuff in one separate package. Reasons
behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
being not installable simultaneously, are same for my and your
proposal.

All my above comments assume that dbus control plugin implements same
semantics as jackdbus. In particular that semantics of control and
configure interfaces are not changed.

ATM, probably because of bugs, dbus control plugin is not getting proper
setings and is not writing messages to the log file. It may be an
implementation bug, but it can be also a design issue with control
plugins that does not allow it.

D-Bus is just a mean to implement features that are needed for LADI
stuff. D-Bus is not a goal by itself. If your implementation does not
provide the features that my implementation provides, it is not
acceptable from technical point of view. Major features in jackdbus
(with comments inlined):

 * Broadcast about jack server start/stop and shared control over jack
   server.

Both implementations seem to provide this through D-Bus.

 * Simplified single thread model for control and monitor
   applications. Various D-Bus language bindings make it trivial to
   write control and monitor applications using scripting languages like
   Python, Ruby, Perl, etc..

Both implementations seem to provide this through D-Bus.

 * JACK has log file that is available for inspection even when
   autoactivation happens because of first JACK application is launched.

Not available/working with your controlplugin implementation.

 * There is real configuration file used to persist settings that can be
   manipulated through configuration interface of JACK D-Bus object.

Not available/working with your controlplugin implementation.

 * Improved graph inspection and control mechanism. JACK graph is
   versioned. Connections, ports and clients have unique (monotonically
   increasing) numeric IDs.

Both implementations seem to provide this through D-Bus.

 * High level abstraction of JACK settings. Allows applications that can
   configure JACK to expose parameters that were not known at compile
   (or tarball release) time. Recent real world examples are the JACK
   MIDI driver parameters and support for FFADO driver in
   QJackCtl. Upgrading of JACK requires upgrade of QJackCtl in order to
   make new settings available in the GUI.

Both implementations seem to provide this through D-Bus.

I'm pretty sure that log file not working in controlplugin branch is
implementation bug. I'm not sure about the configure interface and
settings file though. "jackd -C dbus -R -d alsa -p 512" suggests that
there may be design issue with how settings are handled.

Also we need to clarify whether controlplugin approach fixes the issues
caused by bad packaging. I tend to think it does not (see my comments
above).

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org