Re: [Hamlib-stationserver] Terminology

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

Greg / All -

This is where I've gotten a bit stalled... I don't think we've reached critical mass on this list for collecting user inputs.

One way to look at this project, I suppose, would be as a matter of putting a network front-end on existing hamlib modules.  Not sure what are the status and/or shortcomings of rigctld... and I think I've seen reference to an XMLRPC mechanism as well.  Maybe Nate or someone else could help bring us up to speed on the prior art?

Meanwhile... in a scratching-my-own-itch sort of way... I've been noodling on the question of the most useful level(s) of abstraction.  The existing hamlib appears to approach this at two levels... one at the individual "rig" level... and another at what I take it is a generic "virtual rig" level.  But considering the enormous variety of existing rig configurations... and what I assume will be a sustained commercial incentive toward product differentiation by adding new and unique features (or at least controls)...  I'm thinking this might not be the most sustainable model.

There does seem to be a natural demark at the level of different CAT interface protocols 'twixt computer and radio.  That appear to be structured largely by different vendors' implementations with perhaps some "dialects" within vendors' lines.  This again, is somewhere I could use some help; maybe someone with more experience in CAT implementations could brief us on the current landscape of CAT protocols?

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.

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!  

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.)  

Just thinking...

- Art KD6O


On Mar 18, 2014, at 4:06 PM, Greg Troxel <gd...@le...> wrote:

> 
> Tony Langdon <vk...@gm...> writes:
> 
>>> So, I think the first thing is to define the scope and that's best
>>> driven by some example use cases.
>> Yep.  Some of the examples I had in mind:
>> 
>> 1.  Single machine use.  Stationserver and the client both run on the 
>> same machine, communicationg via localhost.  This is functionally 
>> equivalent to running Hamlib, except that the client doesn't need to 
>> know what make and model of radio it is using - instead it can 
>> communicate using a generic protocol, and can get information about the 
>> radio's capabilities from the server.
> 
> So by use case, I meant one level up: a story about how programs did
> things to radios and how people people interacted wtih  the programs,
> that didn't presuppose that there was a thing called stationserver.
> Basically, I'm trying to suggest that the existence of stationserver is
> a possible system architecture after requirements are understood.  I'm
> still not really clear on what ought to happen, and what sorts of things
> would be supported - and even what's wrong with the world now.