Re: [Hamlib-stationserver] Terminology
Library to control radio transceivers and receivers
Brought to you by:
n0nb
From: Art B. <ac...@in...> - 2014-03-07 16:30:29
|
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. 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. > 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? - Art KD6O PS - Here's the updated (LAN-only) reference-architecture diagram from the Requirements, which I hope represents our nomenclature correctly. |