Re: [Hamlib-stationserver] Terminology

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

> In some of the threads I have noted a bit of confusion.  Some of that
> may be a "here" thing.  :-D
>
> Of note, it may be helpful to discern between clients and users.  If we
> can agree on the following, it should help in further discussion:
>
> Client -- a program that exchanges data with Stationserver.
> User --	a person using one of more clients.
>
> At a minimum Stationserver should be designed to manage data between
> multiple clients and handle contention between those clients and the
> physical device.

While the client notion is fine, the notion that there is a human using
a client is unnecessarily limiting.


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

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

* one could envision a program that adds to rigctld access control so
  that it can be used remotely

* one could envision a program that adds to rigctld supporting multiple
  connected radios at once

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


So, I think the first thing is to define the scope and that's best
driven by some example use cases.

From an implementation point of view, I wonder if one can spin up
multiple hamlib instances in the same process, each with a radio?  That
seems like an obvious first step if it doesn't already work.

73 de n1dam