[Jack-Devel] Client-Server models are just fine. Please?

[Kjetil Matheussen]

On Mon, Feb 1, 2016 at 1:09 PM, Jörn Nettingsmeier <
nettings at stackingdwarves.net> wrote:

>
> i guess my point in a nutshell is this: if you invent some
> user-friendliness that shields the user from having to manually set up a
> key part of their workflow, you are responsible for making sure they are
> aware what's being done, and ideally learn how to do it/control it
> themselves.
> discoverability, discoverability, discoverability.
>
>
Yes, exactly, and that's one of the points I was trying to make. Starting a
jackd process
in the background without the user knowing is not good. Instead - and this
is my highly
opinioned opinion - the client should sometimes also be the server, and all
the server
options and feedback, should be accessible to the client.
Nothing of importance to the user should be printed to
stdout or stderr, or provided via a string as command line arguments. All
communication
should be formally specified, both options for starting the server, and
feedback from the
server. The driver programmer should assume that information printed to
stdout or
stderr will never be read or understood. And in order for the clients to
show/configure
the server part of the client, libjack should provide common GUIs that all
clients may use. This way, you may use Ardour, for instance, alone, but you
may also start the jack server with qjackctl or jackd first if you want to.
Ardour will
tell you if it is functioning as the server, or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160201/789d1898/attachment.html>