Re: [Hamlib-stationserver] Terminology

[John D. H. <jo...@ha...>]

>
>
> Message: 2
> Date: Fri, 7 Mar 2014 08:30:17 -0800
> From: Art Botterell <ac...@in...>
> Subject: Re: [Hamlib-stationserver] Terminology
> To: ham...@li...
> Message-ID: <CCF...@in...>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mar 7, 2014, at 4:19 AM, Nate Bargmann <n0...@n0...> wrote:
> > Client -- a program that exchanges data with Stationserver.
> > User --       a person using one of more clients.
>
> Agreed for my part.  The "user" is an Actor in UML terms... might be a
> person, might theoretically be an automated process, but in any event I
> think we've decided to only support one at a time.
>
> > At a minimum Stationserver should be designed to manage data between
> > multiple clients and handle contention between those clients and the
> > physical device.
>
> Depending on what we mean by "handle contention" this could be where we
> open Pandora's Box.  It's fairly simple to queue different client's
> requests so they'll be serviced first-in-first-out.  It would be much more
> complicated to implement and operate a feature-locking scheme to privilege
> one client above all others, and I'm wondering whether we might be chasing
> a hypothetical requirement there.
>
>
There is value in placing some privilege/permission requirements on users.
 For example, you may have multiple "listeners" and/or observers of one
radio object.

Code can manage the "speaker" (one who is transmitting) while permitting
others to listen and observe changing operating parameters.

A mechanism should exist in the server code to authenticate, authorize, and
permission clients.  Permissions should be at the action/event level.  E.g.
client 'A' should receive events 1 (rssi), 2 (ber), and 3 (received
traffic) and perform no actions, while client 'B' has all of the events
plus actions 1 (ptt), 2 (transmitted traffic), and 3 (power up/down).



> Since we seem to be leaning toward simplicity I'd propose we adopt the
> former, simpler approach... multiple clients under control of a single
> user, with user inputs processed FIFO regardless of which client forwards
> them.  Of course nothing would preclude someone from deploying simplified
> read-only versions of the client.
>
>
The architecture should be robust and perhaps support multiple tiers.  I
envision the architecture supporting multiple radio (and accessory)
objects.  Those objects should be abstractions and applied to different
physical devices.  A collection of objects can then form a master control
console for a station (or network of stations) with relatively simple
plug-in inclusion.



> > Multiple users may require some higher level handling but at their
> > simplest would appear as multiple clients to Stationserver.
>
> There's also the legalistic question of who is the control operator.  Or,
> to put it more generically, an audibility question; how would we ensure
> that each of the users can be held accountable for his/her/its own actions?
>
>
DO NOT GO DOWN THIS PATH!   It is the station operator's responsibility to
meet the legal requirements of the jurisdiction governing their operation.
 Putting such responsibility on the software is both limiting and a
mistake.  Icom's D-STAR gateway / trust system attempts this, and what is
legal and proper in one country is not in another.  It is a bit of a mess
(somewhat resolved by open source gateways using ircDDB).   Provide the
tools, but leave the policy to the station owner. Provide security,
logging, and audit hooks but don't define or require their application.



> - Art KD6O
>




------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog>  <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>



>