On Thu, 2009-07-02 at 18:40 +0200, Stéphane Letz wrote:
> Up to now, we have 2 proposals for the DBus based JACK server control.
> Please contribute to any points if you think something is missing or
> incorrect.
>
> Thanks.
No, thanks thanks thanks to you for the summary!...
> The 2 proposal (especially the second) may still have implementation
> issues, but I hope they are advanced enough for some comparison to
> take place.
> 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
Good.
> - 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.
Very good.
This matches my personal (as a packager) vision. If you install this
additional package you have the dbus control capabilities, if you
uninstall it you lose them (no harm done). Very easy. I suppose that if
you don't have it installed and the plugin is called a proper message
would be printed saying that the plugin is not available.
This enables a transition to be made easily, back and forth.
It is not so simple in the first proposal as there are _two_ mutually
exclusive packages that implement the basic functionality of jack. You
install one or the other initially and that's easy. But if you want to
_switch_ from one to the other (ie: add or remove functionality), then
that is not straightforward.
> 6) other control IPC would typically be implemented in additional
> control plugins: like jack_control_osc" for an OSC based controler. As
> explained in 4), if several controler are installed at the same time
> over a standard JACK2 package, then the "autostart" behaviour is not
> clearly defined.
>From the packager point of view I strongly prefer '2)' for the reasons
stated above.
'2)' also seems like a cleaner approach, but I'm still trying to find
time to read the whole thread, sorry... :-(
-- Fernando
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org