Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?
Library to control radio transceivers and receivers
Brought to you by:
n0nb
From: Nate B. <n0...@n0...> - 2014-03-07 16:58:54
|
* On 2014 07 Mar 10:42 -0600, Art Botterell wrote: > On Mar 7, 2014, at 4:09 AM, Nate Bargmann <n0...@n0...> wrote > > I will note that there will be requests for certain device specific > > readings/settings and provision will need to be made for that. > > Right... those are the CONTROL and READING objects down at the bottom, > which in addition to their use inside higher-level device definitions > could be instantiated independently to access whatever gizmos a > particular station has on offer. I didn't wish to assume. :-) > This is a bit of a slippery slope, of course. If we think station > users are going to insist on mapping their particular rig's physical > UI literally to the network view, we might as well call it a day on > abstraction and simply slap a web-service facade on each of the hamlib > back-ends. Ha! So true. I understand this issue fairly well. There is a lightly documented "feature" of the control daemons that allows a raw CAT command to be passed through to the backend. As the control daemons share the same parsing code as the test utilities, this exposure is just part of the deal. If a program knows that it is dealing with a specific device/model it could issue raw commands through this path and parse the raw data it receives. I am not sure if that is such a grand idea to carry forward as it certainly destroys abstraction. However, it seems to allow limiting the abstraction and forcing rare/unique features to be supported in a primitive manner. > And if we're only concerned with the single-user application that > might well be the case. The benefits of abstraction come when folks > try to operate equipment they aren't familiar with in detail... > "interoperability" at the User level. I want to see something well beyond the limitations of Hamlib, so please continue proposing. We may want to also consider feature priorities to enable a development roadmap of sorts. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |