Re: [Hamlib-stationserver] Terminology

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

I've been otherwise occupied the last few days, hence my silence.

On 9/03/2014 1:58 AM, Greg Troxel wrote:
> While the client notion is fine, the notion that there is a human using
> a client is unnecessarily limiting.
I agree, some clients can be automated/unattended, others that 
Stationserver sees as "clients" could be actually add-on modules 
providing extra functionality, one example that comes to mind is a 
remote base module.  One of these days I'll find a way to draw some 
examples of possible configurations, and clarify some of the ideas I 
had, so we're on the same page and can toss them over and see if they're 
appropriate for the project or not.
>
>
> Another issue is the scale of stationserver (I just joined the list).  I
> am not entirely clear on the current world, but will try to sketch a way
> things might go
>
> * hamlib runs in a process and an instance controls one radio
Yep
>
> * rigctld is basically an instance of hamlib with an RPC interface, as a
>    way for multiple programs to use one radio.  But, it doesn't really
>    have access control.
Again yep.  Other than a quick test to see how it works, I haven't had a 
lot of chance to play with it, because I have to unload it to use other 
radio control software (this problem being the issue that made me ask if 
there was a better way).
>
> * one could envision a program that adds to rigctld access control so
>    that it can be used remotely
I was going to experiment with using shell scripts from thelinkbox to 
make a primitive client for rigctld, but haven't had the time yet.
>
> * one could envision a program that adds to rigctld supporting multiple
>    connected radios at once
Yep, I see where you're going.
>
> * one could envision a program running on multiple computers with one or
>    more radios per computer that provides a single interface to all of
>    them ("federation").  One might have read-only privs on some radios,
>    and write on another, perhaps to see frequencies of other sub-stations
>    on a multi-multi operation.
This is the next logical step.  I have two radios I want to control at 
this point in time.
>
>
> 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.

2.  LAN use, single control.  Same as above, except that the server and 
client are on separate machines.  Only difference in client 
configuration would be the IP address or hostname of the server would be 
something other than localhost (127.0.0.1 or ::1, depending on IP 
version).  Because I was assuming a single user (see below), I was 
assuming a single network domain, by which I mean either a LAN (a single 
PC being a special case) or in the case of multiple sites, a secure VPN 
such as OpenVPN or IPSec connecting the sites.

3.  Multiple radios - in this case, Stationserver is configured with two 
or more radios.  Clients can use those radios separately, or together 
(for example, using one to transmit and another to receive for crossband 
or satellite operation).  If the protocol can include a timestamp, even 
tricks like diversity reception may be possible if you have two or more 
radios capable of receiving the same frequency.

4.  Multiple simultneous access - here clients can simultaneously use 
the same radio.  It could be one user with 2 devices open at the same 
time, or it could be an automated client (for example, an audio logger) 
and a rig control program running together, or even a rig control 
program on the LAN sharing with a remote base add-on. Another variation 
is where two programs are used together for some reason (for example, I 
might want to use dl-fldigi for tracking high altitude balloons, but I 
prefer the interface of HRD to set the radio's frequency, then let 
dl-fldigi automatically control the VFO from there, while using HRD to 
monitor and tweak the frequency or change other settings.

The terminology I've been using so far:

Client - process that makes use of the services that Stationserver 
provides.  Automated processes that utilise Stationserver services are 
also clients.

Radio - device being controlled - normally a radio, but I am aware 
people want to control other accessories such as rotators as well. I 
haven't thought much beyond the radio case, other than being aware some 
people do have other accessories to control (at this time, I don't myself).

User - A person who accesses the system by use of clients.  Clients may 
be associated with a user, though there can be more than one client per 
user, and automated clients have no live user interaction, although they 
are at some stage configured and managed by a user at some stage (even 
if that "configuration" is to accept the defaults!).

Owner - the person who runs Stationserver and configures the radio (and 
presumably owns the radios and the server machine!).

Add-on - Special clients that provide additional functionality beyond 
what the base level Stationserver would provide.  One example I have 
previously mentioned is a remote base add-on.  This acts like a client 
to Stationserver and provides access to the radio to Internet connected 
users.  The remote base add-on would provide support for multiple users, 
authentication and validation, secure control channels and audio, audio 
compression, access controls (i.e. who can transmit, who is receive 
only, etc).

When I was thinking about new rig control architectures, I was thinking 
of a single user system, where the owner was also the one and only user 
( of the core system), and that's the perspective I have been discussing 
this from, at least as far as the core system is concerned, with more 
specialised functionality being provided by add-ons.

That's just the place where I was coming from for input, and may or may 
not be appropriate for a generic system.

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