Chris,<br><br>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. <br>
<br>-Ray KF5HNK<br><br><br><br><div class="gmail_quote">On Thu, Aug 5, 2010 at 11:13 PM, Chris Albertson <span dir="ltr"><<a href="mailto:albertson.chris@gmail.com">albertson.chris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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<br>

<div class="im"><br>
<br>
</div><div><div class="h5"><br>
</div></div></blockquote></div><br>