[hpsdr] HPSDR software direction

[Ray Page]

Chris,

It is readily apparent that you have a deeper understanding of how to
implement inter-module "object" communication than I. Since I am a hardware
monkey, I do tend to think of pipes and valves. To me, the DSP engine is
something that just needs to get data and be told what to do with it.  In
any case, the DSP server (or object) should be "stand-alone", so it can run
on a machine separate from the machine running the GUI if desired. I'll have
to defer to the software weenies to come up with an interface definition
that fits this topology best.

-Ray KF5HNK



On Thu, Aug 5, 2010 at 11:13 PM, Chris Albertson
<albertson.chris at gmail.com>wrote:

>
> 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.   This kind of
> thing makes for a complex interdendancy where modules can't be independently
> developed.   In this example you could not add support for different
> hardware without modifying the GUI because the GUI needs to know about what
> hardware is available so it can tell the DSP engine about it.   Software is
> full of problems like this unless yu think about it and make some
> cast-in-stone rules.     If one is "information about an object will be
> stored ONLY within the obectitself then the GUI would query the hardware.
>  The method would be to broadcast a querry like "any SDR front ends in the
> room?" then zero or five might respond.  Later it might ask each for details
> one SDR front and at a time.         I would let Object" be defined by the
> person building it.  But any object needs a certain minimum set of abilities
> like to be able to respond to broadcast queries.  Like;y a hardware object
> would include the hardware plus some kind of "driver" or "wrapper".    We
> need to get out of the mode where we think of interface as a pipe, no it is
> a language that you speak to your peers with.  The language might sund like
> this "Mr. DSP, I want you to take data from paul and send it to joe."  DSP
> would them ask both Joe and paul abut who there are and what they can do.
>  The person making the request never has to hold information that describes
> DSP, Joe or Paul.  So if Joe contains plug-in devices and one of those gets
> un-plugged no one has to be told abut the un-plug event
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20100806/59239511/attachment-0004.htm>