Jamulus - overall design approach

[pljones]

With the introduction of the JSON-RPC client and server interfaces, we now have two methods of interacting with Jamulus that can be used alongside each other to a certain extent. We actually have to remember there's the command line, too - "headless" with no JSON-RPC.

In vaguely "Computer Science-y" terms, the GUI and JSON-RPC and command line interfaces form "Controllers". They're controlling Jamulus CClient or CServer. CClient and CServer, then, form "Services".

So it should be possible to create a CClient or CServer instance to be used with any combination of the three (existing and any future) Controllers. I'm thinking that main.cpp should create either CClient or CServer, put it on its own thread, and then create the requested controllers, passing the necessary handle to receive signals and trigger slots on the service class.

This means no more direct access to CClient or CServer by pointer or reference and no more shared data e.g. via CSettings - information would only by message passing across threads. This should bring be a performance benefit, as it decouples the "slow" controller thread(s) from the real-time service threads.

It also means that CClient and CServer are where everything is known about state for the client or server. There would be no "held state" in the GUI or JSON-RPC controllers or in CSettings. That means it's easier for the GUI and JSON-RPC controllers to co-ordinate their views of the state held by CClient or CServer (so we have "model" in the service and "views" managed by the GUI or JSON-RPC "controllers", if you want to think in "MVC"-type architecture).

Jamulus already makes heavy use of signals and slots, in effect having been originally designed with the above architecture in mind. However, lots of the system now "takes for granted" there's a handy reference to pClient or pServer or pSettings, so there'd be a fair bit or work involved.

We'd have to make a decision regarding continued use of the Qt toolkit, of course -- it looks like debian now offers Qt6, so my own concerns there are lowered. (It'd be nice to get Qt6 for Windows packaged and available without having to create an account... That's about all that's blocking me.)

[ann0see]

This sounds like a good idea but also a lot of under the hood work.
I think @softins should know about that and @dakhubgit & @pgScorpio who complained about the current design might have some valuable input.

Getting away from Qt is another issue but could be combined.

I‘ll comment later on this topic.

[pgScorpio]

I agree with @pljones.
I think, besides a CSettings we should also have a CStatus and all user controls should only use the signals and slots of CSettings and CStatus.

I already have some WIP experimenting with this, but I had little time recently. Probably I have some more time again soon...

[pljones]

I've actually got as far as a usable rewrite of the command line options and settings system now. It seems fairly reliable... I've not quite got as far as trusting it, though. Whilst it's (meant to be) backwards compatible with the current settings, it's got it's own "newer version" format (so yes, yet another version of stuff to keep backward compatible, if we go this way).

But that was a different aim - centralising configuration of the Client and Server, so that both command line and settings were "the same thing". It does include moving all the direct accesses of CSettings out of all the code (achieved by getting rid of CSettings entirely...) but I've not quite tidied it up so that the settings only get handled centrally (I'm in the process of finishing that off).

[pgScorpio]

OK, in my version commandline options are also read and handled by a CCommandlineoptions class in CSetings, though fully compatible with the current versions.