[Hamlib-developer] Moving rig_cache out of rig_state into private storage

[George B. <geo...@gm...>]

A large portion of the code I have added to Hamlib over the past year+ 
has been to enable moving some fixed structures out of rig_struct into 
somewhat more flexible calloc'ed structures.  Now I've gotten back to 
implementing those, starting with rig_cache(Issue #1420).  After 
thinking about it quite a while, I'd like to do this a bit differently.

I think the rig_cache structure should be completely internal to Hamlib, 
and not visible to the calling application.  Deprecating the definitions 
in rig.h and adding the new declaration to src/cache.h allows us 
complete freedom to modify/enhance/rework the caching operations without 
worrying about outside effects.

Also -

  * This is much closer to current programming techniques.  Data and
    implementation details should be hidden from the outside world, and
    only the API (external interface) should be seen. Even within Hamlib
    the cache won't be visible without '#include "cache.h"'.
  * Reduces the possibility of the app/library mis-match in definitions
    or allocations.
  * In the event of major changes, removes the need for extra
    programming to satisfy older data accesses.
  * And the big technical impact - if Hamlib ever going to handle rigs
    that send unsolicited data (Auto Information in Kenwood speak), then
    the whole notion of cache needs to change - STATE(rig) should always
    be up to date, commands sent to the rig should be confirmed
    automatically, and cache timeouts should no longer be a factor. 
    There may not even be a rig_cache buffer in that case.

I have been running a version of these changes for about a week now, 
using CQRLOG and WSJT-X-improved with no ill effects; I hope there's no 
big use of this data elsewhere. If so, I can add something to freshen up 
the deprecated space in rig_struct, but I reallllllllly hope we can put 
that practice behind us.

Comments and opinions please (to the list).

-- 

73 n3gb