Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

> Ha!  So true.  I understand this issue fairly well.  There is a lightly
> documented "feature" of the control daemons that allows a raw CAT
> command to be passed through to the backend.  As the control daemons
> share the same parsing code as the test utilities, this exposure is just
> part of the deal.  If a program knows that it is dealing with a specific
> device/model it could issue raw commands through this path and parse the
> raw data it receives.

I guess a big question is the purpose.   I see multiple purposes for rig
control software:

  generic use, where a program (logger, fldigi, etc.) wants to control a
  radio in frequency, maybe filtering widths, or maybe just read
  frequency.  Here the point is to hide the radio's details so that the
  program works with any radio (that's adequately capable)

  implementing a GUI front panel replacement where there are controls
  for everything on the radio.  I don't find this super interesting
  except for remote operation.

  writing test equipment, likely for a specific radio, to do RF noise
  level surveys, etc.


But all of these seem to apply to hamlib and perhaps the rigctld
language, independently of stationserver.  Some things can be made
common, and that's great, but the details will always differ.

So I see stationserver adding access control, multiple radios, and
perhaps (big if) multiple computers federated.

Am I totally missing the point?