[Hamlib-developer] Re: [Orsd-discuss] What about Hamlib?

[Stephane F. <f4...@fr...>]

[message crossposted to hamlib-developer mailing list]

On Thu, Jul 05, 2001, Terje Elde wrote:
> 
> > Looks like you're about to develop something already existing. Have you
> > checked out Hamlib lately? We're just neighbors on sourceforge! 
> > 
> > 	http://sourceforge.net/projects/hamlib
> > 
> > We have abstracted ports (serial, net, etc.), a frontend/backend approach,
> > capability aware, loadable on demand with dlopen, works under Linux/POSIX
> > and Win32 DLL as well (yes, you read it right, module loading works under
> > Win32 with libtool magic!). 
> > BTW, we're not Ham centric, besides Icom/Kenwood/Yeasu.. support, backends
> > already exist for pcr1k, Winradio, AOR, etc. Our design is Open, as is our
> > code (GPL/LGPL). 
> 
> Impressive driver-range.  I'd be very interested in hearing more about how
> you're doing this.  One of the things we have specific focus on is to provide
> abstraction between the driver and the applications, allowing the applications
> to work any radio without caring about driver-specific issues.
  
Surprisingly enough, we have quite the same focus, i.e. to provide
abstraction between the driver and the applications. 

Let's take an example: your application wants to change the frequency 
of the current VFO of the radio, and set it to 88.9MHz.
In the application, whatever radio you use, you will call Hamlib function:

	rig_set_freq(my_rig, RIG_VFO_CURR, 88900000);

where 'my_rig' is a handle of type RIG* for your opened radio, much like FILE*
type arguments are to file buffered functions (fopen/fread/fwrite/etc.).
In fact, Hamlib relies on a frontend/backend approach. The frontend
provide the Hamlib API, and can be recognized by the rig_ prefix to
all the symbols. Hidden behind these wrappers are the backends,
which actualy implements the driver-specific stuff. 

So, in our example, my_rig would have been initialized (rig_init) and opened
(rig_open) in order to attach the handle to a backend, and then open the port
(whatever it could be, serial, net,..) and communication to the radio.
If you have a look at 'struct rig' (in hamlib/rig.h), you'll see 
a pointer to a 'struct rig_caps', which gather the capabilities of the rig
("herited" from backend).
So, the rig_set_freq function looks pretty much like this:

  int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq)
  {
	if (!rig || !rig->caps)
		return -RIG_EINVAL;	/* invalid arg */
	if (!rig->caps->set_freq == NULL)
		return -RIG_ENAVAIL;	/* capability not available */

	return rig->caps->set_freq(rig, vfo, freq);
  }

Actualy, it's a bit more complex because of rig that cannot target
a VFO, and other details. But I think you get the point.

> > The core library is written in C for portability/interoperability (esp. when
> > it comes to dlopening), but there's already C++ bindings available for
> > user/GUI development. And there's still a lot to do, the API are not carved
> > in stone yet! Comments are very welcome. 
> > 
> > Maybe we could share our ideas in a single and fun project, for the benefits
> > of all. What do you think? 
> 
> Well, C is my preferred language, though some of us are C++ users.
> 
> Then there's the issue of licensing.  I for one would like to see commercial
> vendors being able to take advantage of the software, and integrate it into
> their own products and solutions.  That's often not possible with GPL/LGPL,
> and I'd really rather prefer a BSD license...
 
I for one too, would to see commercial vendors interrested in Hamlib.
And there's no need to abandon software with a BSD license. Starting 
from Hamlib-1.1.2, all the libraries will be converted to LGPL'ed, which grant
user applications the right to be released under any license of their choice.
As as matter of fact, I think that no _GPL_'ed code will remain in Hamlib.

> Other than that I think it would it be great if we could put all of our heads
> together and see what we can come up with.

yeah! great! the more, the merrier!

> Let me warn you though, we're definitively in the earlier stages.
> 
 so are we. untested stuff (esp. backends), still outlining the API,
 but since there's no user-apps yet, we're free to fiddle it!

> Thanks, and sorry for the late reply,
> Terje

No problem, we too are doing this on our free time, 
so this has to be fun!

Cheers,
-- 
Stephane