Re: [Hamlib-developer] API suggestions

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

Frank Singleton wrote:
> 
> So if frontend API says
> 
>     int (*set_freq)(RIG *rig, freq_t freq);
>     int (*set_mode)(RIG *rig, rig_mode_t mode);
>     int (*set_vfo)(RIG *rig, rig_vfo_t vfo);
> 
> backend equivalents for ft747
> 
>    int ft747_set_freq(RIG *rig, freq_t freq);
>    int ft747_set_mode(RIG *rig, rig_mode_t mode);
     int ft747_set_vfo(RIG *rig, rig_vfo_t vfo);
[...]
> etc..
> 
> What do you think ??

 make sense!

freq_t cmd_get_freq(RIG *rig);

Just a word about the {cmd,backend}_get_* functions. IMO, it's not a good
idea to have them return the data immediately, because we may loose
the return code in case of failure. So I would stick with something like 
this:
	int cmd_get_freq(RIG *rig, freq_t *freq);


Your struct channel looks fine, we need also to support splits:
So instead of having only one "freq_t freq" field,
maybe we ought to have

  freq_t rxfreq;
  freq_t txfreq;

and also:

  unsigned long func; /* bitwise OR'ed RIG_FUNC_AGC, NB, et al. */
  unsigned long tuning_step; /* freq_t is not needed here */
  rig_rptr_shift_t rptr_shift; /* repeater shift is not (cross)split */

Not to mention the Preamp/Att state (expressed in dB?), and the selected
antenna too (provided the rig supports it of course).

Correct me if I'm wrong, the purpose of the "struct channel" is designed
to manage freq memories, right? Oh, yeah, it can be convenient
to use it to get the state of the current vfo, all at once! is what
you intended with get_channel/set_channel or is it for memory managment 
exclusively?  maybe both if the memory number is not defined (eg. -1)?

Comments?

-- 
Stephane					F4CFE