So far rig-remote assumes that every rig provides the same features.
This may not be always true.
We may want to defines rig profiles and endpoints.
a profile is a collection of capabilities (freq range, ). This replies to the question: "what rig is this one?"
an endpoint is a couple (ip,port) (if we use rigctl over tcp) or something else (if we use hamlib) this replies to the question: "How can I get to this rig?"
At this point, piloting a rig becomes applying a profile to an endpoint.
Why the above matters:
[ ] some rig may lack some radio modes, so it may be hand to remove the modes that a specific rig doesn't support
[ ] some rig may provide/not provide digital modes and/or analog modes. A mismatch can be misleading
[ ] from the profile some limit on tuning speed (for scanning) and supported frequency range may be imposed to rig-remote so that the user doesn't go outside the capabilities of the rig.
[ ] the entity of the endpoint is required because it is not a capability of a specific rig, it is a configuration entirely relying on customer context/responsibility.
So far rig-remote assumes that every rig provides the same features. This may not be always true.
We may want to defines rig profiles and endpoints.
At this point, piloting a rig becomes applying a profile to an endpoint.
Why the above matters: