[hpsdr] HPSDR software direction

[Phil Harman]

>
> There needs to be a set of rules for defining an interface.   One should
> be that information about an object (I will not call them servers and
> clients, they are all equal "peers") is contained ONLY within the object.
> This sounds easy but it is so easy to violate this rule.  The e-mail
> quoted below does.  He has the GUI telling the DSP  engine about hardware.

Hi Chris,

That was not my intention - in fact the reverse, but I may have understood
your point since the mear mention of 'objects' tends to bring me out in a
rash  :)

My suggestion is that the GUI connects to the server(s) and asks what
hardware/features the server has to offer.

Lets take the example of John's server connected to a Softrock Model X 
and a 4 channel Mercury with Penny.  Let's assume the Softrock is receive
only and crystal controlled.

In which case the server would respond "I've a Softrock Model X, on
14.125MHz sampling at 96kHz, I and Q are 24 bit signed integers  and are
[here] in this format[zzzz].  I also have a Mercury with 4 channels
available, you can select the sampling rate by doing [xxxx] and the number
of channels by [yyyy]....etc".

The user could then decide which hardware he wanted to connect to and what
features.  If the user always wanted to connect to the same hardware with
the same features then this could be saved in a configuration file.

As the DSP server features changes over time then any new features would
be announced and the GUI can either ignore them or be modified to accept
the new option.

This would all be documented in a "standards" document that explains how a
DSP server and GUI communicate.

More than happy to learn were all the logic errors are in my simplistic
view of the word  :)

73's Phil...VK6APH





 1281079250.0