Re: [Hamlib-stationserver] Terminology

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

On 24/03/2014 5:52 AM, Art Botterell wrote:
> Above that level, though, the practical definition of "rig" seems to be "a collection of features flying in loose formation."  The functionality of a "rig" may be defined not just by a particular box, but also by its interconnections with other devices.  Thus, if the functionality of a control interface isn't to be restricted to predictable "generic" functions, we need a way to discover which functions are on offer from a particular server instance.
And then we can get into "virtual rigs", which could represent 
anything.  One possible use for such a construct is to logically combine 
two rigs into one for satellite operation, to enable cross band full 
duplex with two radios that don't have this functionality.  The 
application ultimately controlling the radio would see a single full 
duplex capable rig.   I don't know if there's any advantages to this 
approach as opposed to applications seeing and using two rigs separately.
>
> Once we have that configuration data describing a particular server's set of getter and setter functions... each with its value type (on/off, integer/enumeration, float value, array), permitted value range, units, item label, and probably a text description... I'm thinking a pretty basic set of get and set functions would permit control of... well, pretty much anything, really!
Nice and simple. :)
>
> Perhaps a RESTful web interface, and a JSON document for the station-configuration file (and perhaps also for combining controls and queries, e.g., for when a channel shift means changing frequency, mode and antenna all at once.)
Hmm, web interface? I need to establish the exact function of this, 
because I think of a "web interface" as a front end (which sounds more 
like a client to me in our model), not something further back in the 
chain.  Just trying to clarify and get our terminology straight. :)

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