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

[Kjetil Matheussen]

On Mon, Feb 1, 2016 at 4:39 PM, sqweek <sqweek at gmail.com> wrote:

> On 1 February 2016 at 22:31, Kjetil Matheussen <k.s.matheussen at gmail.com>
> wrote:
>
> >>> to fail. For instance didn't the messages window in the windows version
> >>> of qjackctl show anything
> >>> coming from jackd until autumn 2015.
> >>
> >> that has to do with windows and qjackctl, not with jackd.
> >
> > But it illustrates how flaky the system is when a bug like this can exist
> > for 10 years.
>
> No, a 10 year old bug illustrates nothing but the nature of open
> source. For a bug to be fixed it must (a) be encountered (b) be
> reported and (c) receive developer attention. (a) & (b) is extremely
> hard for qjackctl on win32 because the majority of the userbase is on
> a different platform. Hats off to yourself for stepping up to fill (c)
> and giving win32 some much needed attention, but this doesn't make
> jackd "flaky".
>
>
I understand why things are like they are. I'm not claiming anyone has done
a bad job. Absolutely not. I just point out that things can be better. Had
there been
a libjackserver library, where the server itself had been included,
qjackctl could have linked to that library instead of starting a process
and do very informal and flaky communication between the server
and the GUI.

(Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed
the bug itself)




> Your proposal doesn't make sense in general. It's narrow minded and
> very focused on the GUI application use-case.


No, it's not. I'm proposing to put the jack server into a library,
preferably
libjack. jackd wouldn't stop to exist because of that.



> Anyway, a separate process makes the whole system *more* robust, not
> more flaky. If the jack server is running in the same address space as
> a client, then an error in that client (segfault/buffer overflow/etc)
> can bring down the entire audio system.
>
> But I'm not proposing to remove jackd. If you want to continue using
jackd, you can.


It sounds like the existing configuration mechanism provided by jackd
> enables you to do what you want already (ie. running ~/.jackdrc). You
> can do literally whatever you want in this script. You don't have to
> run jackd directly, you can write a GUI frontend that lets you
> configure options before launching jackd and make ~/.jackdrc launch
> *that*.


That's all good. But as I've pointed out, there's no proper way to find
out what's really happening. libjack should have a 'char *jack_info()'
function
that clients can display, as a minimum.




>
>
The best part about this is that it just works with no change to
> jackd, no change to libjack, and no change to any clients. This is
> UNIX philosophy. We have simple tools and we glue them together. And
> the result is beautiful.
>
> And I'm proposing to extend that thought further by putting the server part
of jackd into a library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160201/b2de6709/attachment.html>