hamlib-developer

[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

Re: [Hamlib-developer] preferences

[Nate B. <n0...@ne...>]

On Thu, Jan 04, 2001 at 12:00:32AM +0100, Stephane Fillod wrote:
> 
> 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 :)

Okay, I'm new and I'll admit to tunnel vision here.  I really wonder if
this isn't a function better left to the applications.  In my view
(admittedly flawed :) I see hamlib as being a virtual radio with as
consistent and simple  API as possible given the myriad of radios and other
devices out there.  I'm not so sure that it's hamlib's duty to maintain
and parse a list of connected radios or even the ports/hosts the
radio(s) are connected.  

IMHO, hamlib shouldn't care what radios are connected as it should be 
the user application that prompts for and maintains this information and
uses it to initialize the connected radio(s) it is asked by the user app to
talk to.  If the radio doesn't exist or if the communications link is
severed or if the wrong radio is selected hamlib should gracefully
report the error and leave it to the user app to prompt the user of the
error and correct it.

I'm thinking that as hamlib becomes network aware, it maybe possible to
connect to it from a remote machine and then control a radio connected
to a third host (yeah, this would be a security hole, but it's too cool
not to do!).  So in this case a preference file might be a hindrance.

I'm not dismissing the idea entirely, but I do believe its use should
likley be as limited as possible.  I guess it comes from my visualizing
hamlib as more of a system type library on the order of libc.

In defense of a library having an rc file GTK+ came to mind with its use
of ~/.gtkrc for themes.  

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton

Re: [Hamlib-developer] preferences

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

Nate Bargmann wrote:
> talk to.  If the radio doesn't exist or if the communications link is
> severed or if the wrong radio is selected hamlib should gracefully
> report the error and leave it to the user app to prompt the user of the
> error and correct it.
> 
	I agree with you.

> I'm thinking that as hamlib becomes network aware, it maybe possible to
> connect to it from a remote machine and then control a radio connected
> to a third host (yeah, this would be a security hole, but it's too cool
> not to do!).  So in this case a preference file might be a hindrance.

  I have this in mind too. A kind of rigd daemon. Some protocols
  already exists. We can do bare stream proxying, or we can
  do rig virtualization by rigd. The second one would incarnate 
  as a new backend.
> 
> I'm not dismissing the idea entirely, but I do believe its use should
> likley be as limited as possible.  I guess it comes from my visualizing
> hamlib as more of a system type library on the order of libc.
> 
  My concern is that every single application using Hamlib would have
  to rewrite its own preference parsing routines, etc.
  The end user would have to struggle with n different file formats
  to declare its radio. 
  libc has /etc/nsswitch.conf et al. and to my mind, Hamlib is a library too,
  ie. collecting/sharing functions which have a relation with each other.

  However, you're right too. Would flexibility be an acceptable answer to your
  concern? Let's say Hamlib supports preference parsing, but it's not
  done automatically, it must be explicitly called (rig_read_pref()).
  This way, programmers using Hamlib have the choice of using the
  simple preferences facility that comes with Hamlib, or creating
  a more comprehensive preference system associated with their application
  or a bigger scheme (eg. registry under Windows).
  In that case, we have to agree upon API calls that will let them
  modify the rig parameters (rig_set_serial, rig_set_network, etc.)
  as rig_read_pref() would do internally.

  Another issue that may have a solution in preferences, is
  the location of backend modules. Right now, programmers have
  to call rig_load_backend() to have support for new rig types.
  This is painfull, and we don't even know in which directory are
  located the modules. Could we have a RIGBACKENDPATH variable
  (or smthg like that), how do we know what files to load?

  A neat feature would be a list of available backends, pretty much
  like tests/listrigs, but without the explicit rig_load_backend().
  That'd be handy so you can select your rig from a listbox...

  As usual, comments are welcome!

-- 
Stephane

Re: [Hamlib-developer] preferences

[Nate B. <n0...@ne...>]

I can't get into CVS, so I'll sit on the mail list. :-)

On Mon, Jan 08, 2001 at 08:28:06PM +0100, Stephane Fillod wrote:
> 
>   I have this in mind too. A kind of rigd daemon. Some protocols
>   already exists. We can do bare stream proxying, or we can
>   do rig virtualization by rigd. The second one would incarnate 
>   as a new backend.

This sounds intriguing.

> > 
> > I'm not dismissing the idea entirely, but I do believe its use should
> > likley be as limited as possible.  I guess it comes from my visualizing
> > hamlib as more of a system type library on the order of libc.
> > 
>   My concern is that every single application using Hamlib would have
>   to rewrite its own preference parsing routines, etc.
>   The end user would have to struggle with n different file formats
>   to declare its radio. 
>   libc has /etc/nsswitch.conf et al. and to my mind, Hamlib is a library too,
>   ie. collecting/sharing functions which have a relation with each other.

In most cases, I think most of the apps will already be writing some
sort of preference themselves, so I'm not seeing the problem with the
end user, but I'm likely overlooking something.

>   However, you're right too. Would flexibility be an acceptable answer to your
>   concern? Let's say Hamlib supports preference parsing, but it's not
>   done automatically, it must be explicitly called (rig_read_pref()).
>   This way, programmers using Hamlib have the choice of using the
>   simple preferences facility that comes with Hamlib, or creating
>   a more comprehensive preference system associated with their application
>   or a bigger scheme (eg. registry under Windows).
>   In that case, we have to agree upon API calls that will let them
>   modify the rig parameters (rig_set_serial, rig_set_network, etc.)
>   as rig_read_pref() would do internally.

Perhaps this is an area where we need interest from the direct users of
hamlib, the application authors and let them tell us what they find
necessary (wishlist?).

>   Another issue that may have a solution in preferences, is
>   the location of backend modules. Right now, programmers have
>   to call rig_load_backend() to have support for new rig types.
>   This is painfull, and we don't even know in which directory are
>   located the modules. Could we have a RIGBACKENDPATH variable
>   (or smthg like that), how do we know what files to load?

As I read the API now, a programmer has to call rig_load_backend() and
test for failure to figure out if a radio is supported, which needs
improvement.  Currently hamlib doesn't provide a list of supported
backends and should in the future, either through a static list in a 
prefs file or dynamically by searching each backend in a given directory
and reporting the list back to the caller.

An environment variable or a pref entry for backend location(s?) is a good 
idea.  I did install hamlib 1.1.0 over the weekend and noticed how the 
backend libs were dropped into /usr/local/lib along with hamlib.so.  By 
default I think it would be a good idea to drop them into their own
directory (/usr/local/lib/hamlib?).  Perhaps even hamlib itself could
live there with symlinks (hamlib.so, hamlib.a) being placed in 
/usr/local/lib.

>   A neat feature would be a list of available backends, pretty much
>   like tests/listrigs, but without the explicit rig_load_backend().
>   That'd be handy so you can select your rig from a listbox...

If the list is static in a prefs file, then it should be built when
hamlib is built.  Again this is probably an area that apps writers could
better guide us.

>   As usual, comments are welcome!

Yeah, well I can't get into CVS to start documenting, so...

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "None can love freedom
 Internet | n0...@ne...               | heartily, but good
 Location | Wichita, Kansas USA EM17hs          | men; the rest love not
   Wichita area exams; ham radio; Linux info @  | freedom, but license."
             http://www.qsl.net/n0nb/           | -- John Milton