[Hamlib-developer] Re: Kenwood backend, etc

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

Quoting Francois Retief <fgr...@su...>:
> Yes. The Kenwood THD7 has a very extensive async reporting system (more
> than the current callbacks in hamlib.) I succeded in getting some of the
> async callbacks to work for THD7.

Great! We'll have to add the new callbacks to the frontend.
However, if I remember well, the "AI" command does not send what has changed 
but the complete status of the rig right after the event happened. 
Is it what you noticed on the THD7?
So the backend would have to remember the previous state, and from the delta,
find and call only the appropriate callbacks. Is it worth the trouble?

> In the process I created the  th_transaction function, replacing the 
> kenwood_transaction.  It supports error checking, can do retries and 
> is tolerant to async messages.  It might also be possible to extend
> it to handle the other kenwood radios.

Yep, and maybe some other ASCII oriented backends may want to clone it..

> > BTW, what is your sourceforge login name so I add you to the developer
> > list. It'll be easier for you to commit directly to the cvs rep.
> 
> I created an account today. login name: fgretief
> Once created I'll commit my latest changes.

okay, you're in. happy hacking! 
There's no written down rules, just common sense. Adding stuff is no problem.
Just ask for discussion on the list if you plan to do major or heavy
changes on the API/frontend.

> I have been playing with a Hamlib binding for Borland's Kylix.
> Should I contribute it to Hamlib? 

Oh yes, sure! please! We have already c++, tcl, and I can see perl
and python bindings which stand out in the horizon.
You can create a separate directory, much like c++ and tcl, coming along 
with a simple sample program illustrating the new binding. This will give 
others (starting from me :) envy and a quick start in Borland's Kylix.

Cheers,
 Stephane