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

[Kjetil Matheussen]

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

> On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:
>
>> Instead - and
>> this is my highly
>> opinioned opinion - the client should sometimes also be the server,
>>
>
> i disagree, most emphatically. the client should never be the server. do
> you want to spend ages figuring out whether a jack problem happened with an
> in-process server or external server, each time a user cries their eyes out
> on IRC? do you want to battle all the conceptual misunderstandings about
> how in-process servers are faster, and out-of-process servers are more
> robust, and sound warmer? why? what's so bad about a clean conceptual
> separation?
>
>
Two reasons:
1. No need to use anything other than Jack. Ardour now has got the option
of not using Jack. Shouldn't
have been necessary.
2. It feels like a server configuration protocol will stabilize faster if
clients also can function as servers
since more code is using it, not just qjackctl.


and
>> all the server
>> options and feedback, should be accessible to the client.
>>
>
> now that is something we can agree on, but that's *completely* orthogonal.
>
> but the way i do it, i open qjackctl and look at the message window.
> problem solved. and i guess i can explain that to users far more quickly
> than you can implement a new message passing API for jackd.
> developer time saved, user understanding improved. two sacred pillars of
> the open source culture.
>
> It works, but the more components you glue together, the higher the chance
is for something
to fail. For instance didn't the messages window in the windows version of
qjackctl show anything
coming from jackd until autumn 2015.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160201/ca9d1408/attachment.html>