Random question… If what I understand is correct, v4 AOG was one program. Then in v5 AgIO was added. What was the reason for two programs? And AOG can only communicate with AgIO, and AgIO talks with the world, right?
I guess if there’s a thread that talks about this, then someone point it out… I couldn’t find anything searching.
Thanks.
Was a simple way to have the chat to hardware run in a separate process, so the OS could schedule things a bit better as AOG doesn’t really use multi-threading much.
May I ask: why are you asking? Do you find an issue with the current approach?
No I’m perfectly happy with AOG now. I was wondering if qtAOG needed to have a separate program for communication like AgIO and to decide that I needed to know why AOG was done with two programs.
So am I right that AOG and AgIO communicate over loopback to each other, and AgIO talks with the world then?
Thanks
1 Like
Pretty much, AGIO <> AOG is internal, but AGIO goes out to the world for ntrip as well.
I didn’t see that this post came from David who’s working on the Qt C++ code.
With my Qt/C++ fork of AOG I do have plans to re-integrate it, although it would still be its own code module. Mainly because on Android it would be better to have a single app running, and all IO in Qt being asynchronous it makes it unnecessary to deal with threads, and still get good performance.
1 Like
Oh so you would have only one program, but the code would be separated in there, instead of mixed together with the rest of AOG, like it appears to be in v4?
Essentially. All the core logic from AgIO in its own class, tied into the main event loop. And instead of the loopback UDP connection, it would just dump the data directly through a signal into the main form.
But in the short term I was going to keep things as they are now, maybe implementing AgIO as a temporary python script for development purposes.