[Hamlib-developer] preferences

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

Let's dust off the drawing board once again: this time, the preference file.

It's almost obvious, we need a ~/.hamlibrc or /etc/hamlibrc where
to store preferences on the connected rigs, like rig type, serial port
parameters, override values (rig modified),etc.
This way, it's easier for different user application to control rigs,
ie use Hamlib, off-the-shelf :)

First, we need to agree upon a preference file format.

* windows style:
  -------------

	; this is a comment
	[Hamlib]
	Backend Path=/usr/local/hamlib/lib

	[my rig name1]
	Serial Path=/dev/ttyS1

	[my rig name2]
	Serial speed=1200


* UNIX style:
  ----------

	# this is a comment
	backend-path=/usr/local/hamlib/lib

	rig "my rig name1"
	serial-path=/dev/ttyS1

	rig "my rig name2"
	serial-speed=1200


Then, we have to agree upon parameters name, at least upon which
that will be shared among backends in the frontend (eg. serial path, etc.).

You've notice the "my rig name1" and "my rig name2". Well, this is to
differentiate from different rigs attached to the system. Let's say
this is a logical name. From this point, I think that the rig_init
API call needs to be modified, as following:

    RIG* rig_init(rig_model_t rig_model, const char *logical_name);

where logical_name refers to a section in the preference file.
Eventually, the model_type can be defined in the hamlibrc file,
and DEFAULT value would be passed to rig_init.
A "logical_name" field would then be added in the rig->state struct.
The parsing of the hamlibrc file would be done by the first call
to rig_init(), all definitions stored in an internal table.
rig_init() would also override default capability with values from
preference file in the state struct (much internal API specification
to be done here).

Since this is a bit tricky with text files, saving preferencies from
Hamlib would not be available, at least from the beginning.


Eventhough Hamlib is coded in C, it's good to have as much as applicable
an OO approach. For instance, messing directly with rig->state.rig_path 
is not very clean, nor flexible for the future.
To my mind, some new API calls should be created:

	int rig_set_serial(RIG *rig, const char *path, int speed, etc.)
	int rig_set_network(RIG *rig, const char *host, int port, etc.)
	int rig_set_whatever(RIG *rig, const char *path, etc.)

The behaviour would be:
* use values from the function arguments
* if args are set to an undefined value, use the ones from hamlibrc
* if none defined in preferences, use capabilities default
* as a last ressort, if the variable has no default value in caps,
  then the function call should fail, returning appropriate error code.


Okay, this is only some thoughts to start up with. I don't mean to impose 
anything. Let me know what you think of it, stuff I omitted,
if you dream of preferences another way (I hear you gnome afficionados :) ...

Thanks for your inputs,

-- 
Stephane