From: Nate B. <n0...@ne...> - 2001-01-08 21:22:49
|
I can't get into CVS, so I'll sit on the mail list. :-) On Mon, Jan 08, 2001 at 08:28:06PM +0100, Stephane Fillod wrote: > > I have this in mind too. A kind of rigd daemon. Some protocols > already exists. We can do bare stream proxying, or we can > do rig virtualization by rigd. The second one would incarnate > as a new backend. This sounds intriguing. > > > > I'm not dismissing the idea entirely, but I do believe its use should > > likley be as limited as possible. I guess it comes from my visualizing > > hamlib as more of a system type library on the order of libc. > > > My concern is that every single application using Hamlib would have > to rewrite its own preference parsing routines, etc. > The end user would have to struggle with n different file formats > to declare its radio. > libc has /etc/nsswitch.conf et al. and to my mind, Hamlib is a library too, > ie. collecting/sharing functions which have a relation with each other. In most cases, I think most of the apps will already be writing some sort of preference themselves, so I'm not seeing the problem with the end user, but I'm likely overlooking something. > However, you're right too. Would flexibility be an acceptable answer to your > concern? Let's say Hamlib supports preference parsing, but it's not > done automatically, it must be explicitly called (rig_read_pref()). > This way, programmers using Hamlib have the choice of using the > simple preferences facility that comes with Hamlib, or creating > a more comprehensive preference system associated with their application > or a bigger scheme (eg. registry under Windows). > In that case, we have to agree upon API calls that will let them > modify the rig parameters (rig_set_serial, rig_set_network, etc.) > as rig_read_pref() would do internally. Perhaps this is an area where we need interest from the direct users of hamlib, the application authors and let them tell us what they find necessary (wishlist?). > Another issue that may have a solution in preferences, is > the location of backend modules. Right now, programmers have > to call rig_load_backend() to have support for new rig types. > This is painfull, and we don't even know in which directory are > located the modules. Could we have a RIGBACKENDPATH variable > (or smthg like that), how do we know what files to load? As I read the API now, a programmer has to call rig_load_backend() and test for failure to figure out if a radio is supported, which needs improvement. Currently hamlib doesn't provide a list of supported backends and should in the future, either through a static list in a prefs file or dynamically by searching each backend in a given directory and reporting the list back to the caller. An environment variable or a pref entry for backend location(s?) is a good idea. I did install hamlib 1.1.0 over the weekend and noticed how the backend libs were dropped into /usr/local/lib along with hamlib.so. By default I think it would be a good idea to drop them into their own directory (/usr/local/lib/hamlib?). Perhaps even hamlib itself could live there with symlinks (hamlib.so, hamlib.a) being placed in /usr/local/lib. > A neat feature would be a list of available backends, pretty much > like tests/listrigs, but without the explicit rig_load_backend(). > That'd be handy so you can select your rig from a listbox... If the list is static in a prefs file, then it should be built when hamlib is built. Again this is probably an area that apps writers could better guide us. > As usual, comments are welcome! Yeah, well I can't get into CVS to start documenting, so... 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | "None can love freedom Internet | n0...@ne... | heartily, but good Location | Wichita, Kansas USA EM17hs | men; the rest love not Wichita area exams; ham radio; Linux info @ | freedom, but license." http://www.qsl.net/n0nb/ | -- John Milton |