Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

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

Great thoughts, Greg!  Comments below.

On Mar 8, 2014, at 7:04 AM, Greg Troxel <gd...@le...> wrote:
> But all of these seem to apply to hamlib and perhaps the rigctld
> language, independently of stationserver.  Some things can be made
> common, and that's great, but the details will always differ.

Which has me thinking about maybe turning the abstraction issue around.  Given that rigs vary so broadly... and that time may (almostly surely will) see redefinitions of the whole notion of "rig"... perhaps the productive question isn't abstraction so much as discovery.  

In other words, might it work better to expose a collection of primitive input and output types... like the CONTROL and READING objects at the bottom of my earlier outline... along with a mechanism for each server to describe the particular set of widgets on offer to representing the attached equipment?  Perhaps in the form of a JSON or XML data structure... which might also imply the template for control commands and queries?

Seems like such an approach might allow a refactoring of the rig interfaces to be table configured rather than hard coded.  It also would provide a degree of self-documentation... perhaps including some owner-suppled free text to note station peculiarities, e.g., local interference issues, antenna patterns and such.  In any event it might avoid endless arguments about how best to abstract vendor-specific and innovative features.

Focusing on a feature-discovery mechanism might also help with the question of audio (and video and whatever) content transports.  The stationserver could simply assert the codec, rate, any other parameters and location (an IP port number, probably) for the gazinta(s) and gazoutta(s).  (Although reference implementations might help drive folks toward de-facto standardization; for audio I've been looking at www.opus-codec.org / RFC 6716 but haven't played with it yet.) 

Then we could... if we wanted to side-step the whole user/authentication issue for the time being... simply let folks use VPNs for access control if they choose to expose their systems to the Wild Wacky Web.  Or not, if they're bold...

- Art KD6O