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?

>
>
>> 5) the proposed packages scheme is the following:
>>
>> - a standard JACK2 package is defined; is contains "jackd,
>> libjack.so, libjackserver.so headers, tools.... It is the exact same
>> packaging as legacy JACK. It is then  supposed to be used with legacy
>> controler like Qjackctl
>>
>> - an additional package contains "jackd_control_dbus.so" and
>> "jack_control" DBus based controler to be installed on top of  
>> standard
>> package. It is then supposed to be used with new DBus based
>> controlers.
>
> 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).
>