Regarding the thoughts on a rig control "server" if you will.
Bruce mentioned rigctld about which I replied currently lacks what I
believe are certain critical features, among them security, proper
handling of mutliple clients, and no sequence control for commands.
While there is little question that these issues could be solved, Tony's
comments sparked some thought about the direction something like this
could go. I am unsure if others were considering a server that is only
embedded in White Box or something more general.
For one, I like the idea of a server type application for rig/rotor
control, and was why I proposed rigctld as it is and Stephane, F8CFE,
did most of the coding for it and rotctld in Hamlib. I really think
that a network server is the way forward as it offers several advantages.
With a command language that is ASCII (one may want to refrain from
UTF-8 for this purpose), the connecting application can be written in
any language and still utilize the server. Linkage to a C library API
or via some translation shim is not required. I'm satisfied that
rigctld has shown this to be a good direction.
Should someone choose to develop a general use rig control server
(beyond anything embedded only in White Box) then the following ideas
might be worth consideration.
* In the short term, have the server link to Hamlib. Doing so buys a
lot of access to various rigs in the short term as the server is
stabilized.
* Develop a method for defining radio/rotor commands and ranges that
don't require writing source code. Dave, W1HKJ, has done this with
the RigCAT XML files used in Fldigi. This can serve as inspiration.
In Hamlib adding a new radio/rotor model requires hacking C source
which has likely turned some folks away or requires a developer to
write the code and then engage in a sometimes lengthy
write-test-rewrite cycle that works until the formerly interested
party loses interest. Ideally, this would be no more complicated
than key/value pairs (the format of glib's keyfile comes to mind).
* As the server's backend definitions are completed the reliance on
Hamlib can be reduced and finally eliminated at some point in the
future.
* The server should have full support for handling radios that can do
auto-updates of their status and do so while handling multiple
clients. Hamlib has a few definitions that recognize that a number
of radios have the capability, but (to my knowledge) lacks the
infrastructure to handle it.
* The server could offer a rigctld/rotctld compatible command set in
addition to its native command set. This would aid in transitioning
existing software to work with the new server.
My notes only involve rig/rotor control as that is what I am most
familiar with having contributed to Hamlib in various capacities over
the past 13 years. I like the idea of also handling audio in some way
but I have zero experience other than getting ALSA going in years past
and now selecting the desired audio sink in PulseAudio Volume Controlon
a per app basis.
Is anyone seriously interested in developing such a server? If so, I
can offer resources of the Hamlib project on SourceForge such as a Git
repository, mailing list, and files archive. I'd like to offer my years
of experience with Hamlib to help design a better rig/rotor control
product.
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
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
