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

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

* On 2014 03 Mar 22:25 -0600, Art Botterell wrote:
> 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.

I like these perspectives, Art.

I can see them clearly now, thanks.  Hamlib the library is of the
processor-centric perspective and the control daemons were a baby step
into the network-centric perspective.  It may be of interest that my
"day" job is telecom so those terms are just as familiar to me and why
I've thought for a long time that network-centric is the better way to
proceed.

> 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

Very good.  Defined interfaces and modularity are the hallmarks of sound
design, IMO.

> 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!

This is clearly thought out well beyond any consideration I gave to any
of this and that is a good thing.  I think the "freedom to adapt as
technology and user perspectives evolve over time" is going to be a
critical component of this project moving forward.

Looking very good, guys.

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