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

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

On 4/03/2014 9:53 AM, Art Botterell wrote:
> Started some very preliminary doodle of the object models, and looking at the rigctld man page it occured to me that a number of the commands are really pass-throughs of legacy UI mechanisms.
>
> E.g., there are a variety of options for RIT (and XIT), split and repeater shift... all of which are really just ways of making the transmit and receive frequencies different according to various rig interfaces and technology legacies.
>
> Seems like it might be cleaner to abstract all that out and simply model each receiver and each transmitter as having independent frequency and other settings that might or might not happen to be the same at any point in time.
I like this Art.  Certainly for split, VFO A/B, etc, all these could be 
handled in one API.  We could try doing repeater shift the same way, and 
only use shims where necessary.
>
> Which might require adding some rig-specific shims to order up the required configuration in language each particular rig understands... and of course, familiar mechanisms such as RIT, split or shift could be reproduced in client UIs as folks desire.  But I'm thinking what we're really after is a universal abstraction layer... or at least as universal as we can make it... rather than just passing through every CAT command there might be.
Agree totally.  The only thing the clients should know about the 
connected radios is the capabilities.  For example, the client needs to 
know I can't dial up 14.200 MHz on my FT-736R, or 1296.100 on the 
IC-7000 (it should get an error if I attempt to do these things), but it 
doesn't need to know how I implement repeater shift, RIT, XIT, etc.  It 
just needs to request these functions and let the server work it out, 
since the server has the information it needs to best communicate with 
and configure the radios.
>
> However I suspect this isn't a new dilemma, so I'd appreciate any background or insight anyone can offer.
>
> Thanks!
>
> - Art
>
> Also, I'm not seeing a lot of support for control of various filtering options.  As that's been a competitive feature among rig vendors it may be another area where we have to decide whether to abstract or accept various proprietary styles.
Might need a bit of research to determine the best approach.  The 
IC-7000 brings out 3 bandwidth settings (called 1, 2 and 3, with 1 being 
the widest), but these in turn can be configured elsewhere in the 
menus.  Also need to handle errors for radios that report errors when 
trying to select nonexistent filters (or be able to configure this 
capability in the driver setup - nonexistent filters could cause 
confusion for remote base users).  I have no idea what other radios do.

I'm for abstraction where possible, and only going proprietary where 
there's no viable alternative.

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