You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue I'm running into is that querying the rig for its frequency is expensive. There's no good way to throw in a caching layer, but if Rig was an interface I could easily add a CachedRig that wrapped a rig and cached all of the Rig get calls for a few seconds to save calls to the radio.
Thoughts?
The text was updated successfully, but these errors were encountered:
I guess sooner or later everybody runs into this kind of bottleneck issues with hamlib ;-) One solution might be to change from polling to the hamlib callbacks which inform about changes. Although I've heard that the callbacks are not implemented in all backends.
In gorigctl, which is intended as a rigctld replacement, but using Protobuf instead of plain TCP sockets, I added a caching layer between the RPC calls and the radio connected via goHamlib. I defined there a radio interface and then implemented it for a local and a remote radio.
But I understand that you want to rather work directly with goHamlib, without an RPC layer in between.
Converting rig into an interface might be a viable option. My main concern is that the interface will have to be changed with each new method call added. Especially since rig in goHamlib currently doesnt implement the full C api for hamlib.
Hey Tobias,
The issue I'm running into is that querying the rig for its frequency is expensive. There's no good way to throw in a caching layer, but if Rig was an interface I could easily add a CachedRig that wrapped a rig and cached all of the Rig get calls for a few seconds to save calls to the radio.
Thoughts?
The text was updated successfully, but these errors were encountered: