Nate - Yep, I'd have some energy for this.
My sense is that when we talk about a "server" here we're mostly talking about designing a network protocol / API... and then doing a reference implementation. Designing the abstraction layer will, IMHO, be the really crucial bit. Based on experience with the Common Alerting Protocol and the Emergency Data Exchange Language projects, I'd throw out the following as a possible approach (it's somewhat but not strictly sequential): 1) Establish the project framework... website, mail list, file repository... and also the IP strategy (e.g. I might suggest Creative Commons for the docs and the MIT or Modified 3-Clause BSD license for reference code*) and invite anyone who's interested to take part; 2) Compile and refine a requirements document (seems like we've got a running start on that bit); 3) Develop and refine a domain object model to clarify concepts such as "rig," "signal," "server," "client," etc. 4) Develop and refine a data dictionary to specify the necessary semantics; 5) Develop and refine schemas (schemata, for the rigorous and/or pedantic!) for the various transactions; and finally, 6) Develop, test and refine some reference implementation code. So Nate, if you'd be willing to set up a workspace I'd be glad to start by compiling a strawman requirements draft. Probably best if we moved any further process discussion to the project list. - Art KD6O * Basically, these would establish that anyone could do anything they like with the work product, and nobody could prevent anyone else from doing so. On Mar 2, 2014, at 8:00 PM, Nate Bargmann <[email protected]> wrote: > 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 > > -- > You received this message because you are subscribed to the Google Groups > "digitalvoice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/digitalvoice. > For more options, visit https://groups.google.com/groups/opt_out. ------------------------------------------------------------------------------ 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
