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