Re: [Hamlib-developer] Future direction of the Hamlib project

[Martin A. <aa...@ew...>]

Dave Hines wrote:
> ...
> This set of layers could be split into two programmes, with the split
> occurring at one of the layer boundaries - probably between layers 2
> and 3. If this was done, the link between these layers could be made a
> network link, so the control programme could be run on a computer
> remote from the machine to which the radio was connected. Remote
> control of a rig would thus become easy.
> 
> Layer 3 itself should be made so that several instances of it could be
> active at the same time, so several rigs could be controlled in the
> same programme. This might be by writing it as a class, if it is
> written in an object oriented language, or by keeping it's data in a
> structure.
>  ...

The "layers" idea is similar to, for example, the OSI model 
(http://en.wikipedia.org/wiki/Osi_model) for communications.  Not a bad 
strategy.

I would like to point out that the "layer 3" is not quite enough by 
itself.  It's not just a matter of one application talking to multiple 
rigs, although that is a good thing, but we also need multiple apps 
talking to a single rig.  The current software does not really allow 
this (except maybe through the RPC method), and I have run into trouble 
when I want to use independent programs for rig control, logging, and 
PSK31 operation.  They all want to access and/or control rig info.

The OSI model does allow for this in the session layer, according to my 
limited experience. But of course our rigs don't know anything about 
sessions, so some thought about multiplexing, re-entrancy, atomic 
behavior, etc. would be necessary.

All this is to suggest that if we're doing a new API, we need a lot of 
preliminary discussion about functionality and architecture.

It should be fun, but it will take some time if we have to do it by e-mail!

73 Martin AA6E