Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

[Nate B. <n0...@n0...>]

* On 2014 03 Mar 16:54 -0600, Art Botterell wrote:
> Started some very preliminary doodle of the object models, and looking
> at the rigctld man page it occured to me that a number of the commands
> are really pass-throughs of legacy UI mechanisms.  
> 
> E.g., there are a variety of options for RIT (and XIT), split and
> repeater shift... all of which are really just ways of making the
> transmit and receive frequencies different according to various rig
> interfaces and technology legacies. 

There is a, as we call it, a "virtual rig" sort of abstraction to the
Hamlib C language API, although this is poorly reflected by
rigctld/rotctld (from now on I'll refer to them as the "control
daemons") which are essentially a "flat" command namespace.
Unfortunately, there is no document available that outlines this
abstraction.  Each programmer using Hamlib's C API has had to figure it
out, often by reading the header and or source files.  Certainly, any
willing backend contributor has had to do the same.  This has greatly
limited Hamlib's currency with new rigs.

Also, Hamlib's virtual rig only supports three VFOs, A-C, for example,
which are certainly far too limiting for the modern rigs coming down the
pike.  Originally, the goal was to support all features of available
rigs in the virtual rig interface.  In 2000 when the project went public
this probably seemed like an attainable goal.  Today, not so much as it
is just not practical, IMO, to try and include the unique features of
every model.

> Seems like it might be cleaner to abstract all that out and simply
> model each receiver and each transmitter as having independent
> frequency and other settings that might or might not happen to be the
> same at any point in time.
> 
> Which might require adding some rig-specific shims to order up the
> required configuration in language each particular rig understands...
> and of course, familiar mechanisms such as RIT, split or shift could
> be reproduced in client UIs as folks desire.  But I'm thinking what
> we're really after is a universal abstraction layer... or at least as
> universal as we can make it... rather than just passing through every
> CAT command there might be.
> 
> However I suspect this isn't a new dilemma, so I'd appreciate any
> background or insight anyone can offer.

Perhaps one question would be, how should a radio "look" to a calling
application?  By that I mean that it may not "look" much like a radio at
all.

My reading of Hamlib over the years has led me to understand that its
API tended to mirror the way we humans approach a radio.  We have knobs
and buttons and the API reflects that through C functions that mimic our
interaction with the actual radio.  At first glance it makes sense, but
does it make any more sense than the earliest GUI programs that were often
patterned after a generic transceiver front panel?  Quite likely not.  A
different paradigm now exists for the UI for rig control so perhaps as
well, a new paradigm should be developed for the way we control it via
software.

I look forward to seeing the ideas here.

> Also, I'm not seeing a lot of support for control of various filtering
> options.  As that's been a competitive feature among rig vendors it
> may be another area where we have to decide whether to abstract or
> accept various proprietary styles.

Hamlib supports filter selection as part of setting the mode.  If a new
bandwidth is desired the mode is set with the new bandwidth.  It is up
to the backend to work out the details between the virtual rig and the
hardware.

My explanations of Hamlib's implementation are for the collective
reference and not to tilt the discussion one way or the other.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us