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

[Tony L. <vk...@gm...>]

On 4/03/2014 3:23 PM, 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.
I just see things my way.  How that fits into these paradigms, I don't 
know. :)
>
> 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.
Yeah, that works too, I can see opportunities to have multiple radio 
servers in a networked arrangement that clients just see as nodes.
> >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.
That makes sense to me, probably similar to how I see the project, 
though expressed differently.
>
> And between those components we have a series of interfaces:
>
>      USER <=> User Interface <=> CLIENT <=> Network Interface <=> SERVER <=> Device Interface (e.g., CAT) <=> RADIO
Yep, with branches off the side at both ends for things like digital 
modes. :)
>
> 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.
That's why I like abstraction - interoperability.
>
> 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.
That's probably a good starting point, though in the long run I'd like 
the backends to be definitions, rather than actual code. Something non 
programmers can edit, with or without the help of a "radio editor" 
program to assist with the syntax.  It would be nice to have a 
consistent and well documented virtual radio to work with, which would 
be what the clients are actually interacting with.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com