Re: [Hamlib-developer] Proposal

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

On Sun, Oct 08, 2000 at 04:08:56PM -0500, Frank Singleton wrote:
> 
> I have been writing some dissectors for a cool opensource
> project called "ethereal". see http://www.ethereal.com/
> 
	I'll give it a look tomorrow.

> Anyway, we use glib and gtk, and that goes a long way
> to helping support multiple platforms. Ethereal
> compiles and runs on Unix (+flavors), Linux, window$ etc..
> 
  Well, I've already asked myself if glib would be of any
  help for Hamlib. In some cases yes, in other cases not.
  If you ask me for a answer right now, I would say
  no to glib. I know it would make things easier for us,
  but do we need all these gizmos to have a real lib?
  I mean It's so good to have something selfcontained,
  that does not require you to install xx .DLL^H^H^H^H
  shared libraries to run.
  REM: I do recognize glib has plenty of cool stuff, and is very
	portable.

  Ok, that's my answer today. It could change, especially if
  we need more and more of this kind of reusable code.
  Actually, this is a point where I'd love to see other
  developpers (other than you and me) debate upon...


Fresh news:
----------
* added dynamic backend loading (still need the LD_LIBRARY_PATH though)
* a new listcaps to list all known caps
* include/rig.h moved to include/hamlib/rig.h
* file buffered access, this works in parallel with unbuffered.
	It lets you do read 1 byte at a time, at no IO penalty.
* added transceive mode, ie. asynchronous rig notificication handling
	It works quite nice with SIGIO and sigaction. see testtrn
* More icom stuff

For details, please see cvs-digest

So what do you think of what we got? Can we make a hamlib-1.1.0
release and call for help? We DO need help to finalize the API,
choose the function names and semantics, etc.
Potential Hamlib users are already knocking at the door!

Cheers,
-- 
Stephane Fillod				F4CFE