[Hamlib-developer] Re: API suggestions

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

Frank Singleton wrote:
> 
> Actually now that I think about it, the cleanest approach
> is probably for the frontend API to provide as a minimum functions
> like 
> 
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)
> cmd_set_freq_(RIG *rig, freq_t freq)
> cmd_set_filter_(RIG *rig, filter_t filter)
> 
> and in general
> cmd_set_xxx_(RIG *rig, xxx_t xxx)

and cmd_get_xxx(RIG *rig, xxx_t *xxx)
REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
     unability to check the return code.

BTW, is the "_" in "cmd_set_xxx_" a typo ?

Also, I'm thinking that the "cmd_" prefix can generate some namespace
clashes (well, no if the other objects is not dealing with vfo's 
and ham specific stuff :). Anyway, would it be better to have this:

	rig_set_mode(RIG *rig, rig_mode_t mode)
	rig_set_vfo(RIG *rig, vfo_t vfo)
	rig_set_freq(RIG *rig, freq_t freq)
	rig_set_filter(RIG *rig, filter_t filter)

Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
Should you see any concern?

About convenience functions like:
> 
> cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> ....,,,, filter_t filter..)
> 
> is some frontend convenience function that backend libs can handle
> either directly as is toward the rig if the rig can handle it that way, 
> or the backend lib breaks it into the simpler functions shown above if 
> the rig needs it that way. We dont care up the front how its done
> int the back of course (apart from efficiency issues of course)!
> 

In your previous mail, you were proposing that we can pass NULL
parameters into the cmd_set for those things you
dont want to change since previos command. Well, it depends
on what your understanding of NULL. For instance, 0 can be meaningfull 
for the vfo_t type, etc.  (anyway, we can use -1)

> 
> Ok, now I sleep better !!
> 

Sometimes, coding is like certain ham bands, 
it's only open at night :-)


-- 
Stephane					F4CFE