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

[Art B. <ac...@in...>]

Thanks, Nate. 

If I may make a general observation:  There are two common perspectives on a project like this, in my experience.  They're both valid and they're so similar that sometimes folks miss the subtle difference between them and wind up talking past each other.  I call those two approaches the "processor-centric" and the "network-centric" views.

The processor-centric view, as the name suggests, puts a computer in the middle of the mental model.  This is typically how software folks view problems.  The term "API" is a often a signature of the processor-centric perspective.

Telecommunications folks, OTOH, tend toward the network-centric view.  They talk about "messages," "protocols" and "exchanges" and tend to see the wire (or the cloud) as the center of things and the processors as nodes... leaves on the network tree... and largely treat them as black boxes with (hopefully) standardized interfaces.

Again, both views are valid in their own domains.  The trick I've had to learn is to recognize which perspective is being use at any point in time.  Although I've written a fair bit of code over the years I'm a comms guy at heart and thus my personal dominant mode is net-centric.  

That said...

On Mar 3, 2014, at 7:13 PM, Nate Bargmann <n0...@n0...> wrote:
> 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.

From a net-centric view I'm thinking it should look like an instance of an abstract, Platonic-ideal model of a radio... composed of building-block components... transmitters, receivers, filters and so on... that can be assembled to describe any particular device.

The "server" is a gateway between the IP network environment and the digital controls on a radio... and a "client" is a gateway between a human (or non-human) user's inputs and the IP network that's compatible with the server's capabilities.  Like a radio each is made up of internal components that are (again hopefully) highly modular.

And between those components we have a series of interfaces:

    USER <=> User Interface <=> CLIENT <=> Network Interface <=> SERVER <=> Device Interface (e.g., CAT) <=> RADIO

We achieve interoperability by eliminating unique or instance-specific features of the shared network interface... but at the edge interfaces (the client UI and the radio CAT connection) we can still accommodate diversity.

Which means that client user interfaces could, at least in principle, be customized to fit whatever paradigm the user knows or prefers.  E.g. a client could offer a RIT widget that looks and works just like RIT traditionally does... without necessarily implementing a literal "RIT" command on the network interface or even using that literal feature on the device interface.

In other words, taking the network interface to a higher level of abstraction doesn't mean not giving users an interface they understand.  It just makes interoperability a lot easier behind the curtain and on the wire.  And it gives more freedom to adapt as technology and user perspectives evolve over time.

My thought at this point, therefore, is that in the near term we'll be designing a network "facade" interface to the existing hamlib virtual rig and rig-specific backends, enabling a variety of stationserver-compatible clients to offer different UIs to different users and for different applications.

Once we've done that it may make sense to work back into the hamlib codebase and see if that can be streamlined or otherwise improved.  (I'm guessing that by taking a less literal approach to the individual rig interfaces it may be possible to simplify it.)  I'd expect that the individual rig interfaces would be the last thing to refactor, except in cases where there are serious shortcomings or, of course, when there are new radios to support!


- Art