Re: [Hamlib-developer] frontend API function reduction

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

On Fri, Sep 15, 2000, Frank Singleton wrote:
> 
> Well nothing compiles now (sob), so lets get the
> general API and interwork API firmed up...
> 
Sorry about that, I forgot to let you know in my previous mail...
Acutally, I was so eager to show off the new frontend/backend approach!

Usually, we don't write the software specifications after the development :-)
The same goes for an API implementation. 
So it doesn't matter much if the code is broken if the API is not yet
specified! We're still in ALPHA stage, after all. Clean compiles is yet BETA
(and considered stable for MS :).

> I am keen to get a good general (extensible) infrastructure in place.
> 
good! let's do it!

> eg: If previous co compiles, and your or my next ci is known
> to break this, we should think about tagging it in CVS.
> 
	Agree with you! To me, the hamlib-1.0.3 is the latest
  clean compile. Also about version numbers, would it be better
  to have odd numbers for development phases, and even number
  for stable code, ala Linux kernel? With 1.0.3, people
  might think that the library is already ready to use (which is not!)

>
> backend must implement all opcodes (of course)

  ..provided we have the specs. May be we can sumon some help
  by sending an announce on lin...@vg...
  and lin...@de... mailing lists.

> This creates a large function namespace, this is ok as there
> shall be wrappers for them up front anyway. Also, bakend must test
> all opcodes anyway.
> 
> However, frontend should have reduced namespace for function calls.
> 
> eg result, 2 functions up front ....
> 
> cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> vfo);
> 
  Looks definitely better this way!
  Just a question: what if the application just wants to change
  the mode only? It might be troublesome in certain case to have
  to remember the current frequency or having to query it.

> 
> so, lets create some enums
> 

allright! more to come I'm sure.


new stuff I've checked in:

serial.c
--------
serial_open()	open and setup a serial port, fully RIG* aware,
		cloned from open_port2()
write_block2() handles optional write_delay
read_block() does passive blocking(select), and have timeout handling
open_port2() has been busted (outdated refs to rig_caps), use serial_open()?

Question: What do you think of write_block2() ? Would you agree 
		to replace write_block() by write_block2() ?

frontend:
--------
rigcaps.h has been cut and pasted into rig.h in order to fix the cyclic
forward references. Updated some data struct, added flow_control/retry/timeout
See the testrig.c example to see how to use the frontend lib.
Note: the Makefiles are still broken..

testrig.c
---------
modified to use rig_init/rig_open. Should work with an operating backend..


Conclusion:
----------
The good news is hamlib now compiles OK back again.
Next stage: the linking  ;-)

I'm sorry Frank, with the new API and frontend/backend, you'll have
to modify your ft847 code. BTW, do all the Yeasu rigs have the same
"CAT" protocol as Icoms do with "CI-V" ? In this case, may be it will
be easier for you to factorize some code.

-- 
Stephane Fillod					F4CFE