On Sun, 2006-08-27 at 20:38 +0100, Bob Cowdery wrote: > I've done a bit more digging. There seems to be three options for > integration: > 1. The arms length pipes (I think this can be TCP/IP as well and > possibly some others (according to some papers I read)). Pipes only work > for *nix so it means an extra sockets hop under Windows on the same > machine.
The situation is expanded considerably if the messaging transpires among distributed Erlang nodes, which communicate only locally with clients in other languages. I think this was the generally-understood model. It's advantageous secondarily in that the distributed Erlang nodes are much more versatile in their error handling and propagation capabilities than the local C or C# or Python nodes would be. > 2. Port Drivers which are effectively shared libraries .so or .dll for > *nix and Windows. This seems to be limited to languages that can create > proper shared libraries, predominantly aimed at C. It certainly brings Python, C#, Ruby, and PHP into the fold. > 3. C Nodes which are definitely C only and receive native Erlang > messages. Once again, wrapping up the C interfaces for other environments like Python and C# is straightforward. I believe I have the Python version living on this machine somewhere. > ...Yes the VR contains the complete > model of the whole system, so yes it contains all the data that the UI > displays, it has static data, it has dynamic data and it has > configuration data and it persists and restores that data. Here we part company. In my view the VR is simply the syntax and vocabulary of the messages acceptable to the radio kernel. In this sense, then, the radio kernel corresponds neatly with a microkernel, in that it's responsible for very little more than message passing and protocol handling, and maintaining just enough state to economize on the former and enable the latter. > This data is > required in various quantities by all nodes of the system, not just the > UI. On this I could not agree less. The goal is to minimize the visibility of the nodes among one another. That's proportional to minimizing the bandwidth requirements for controlling the nodes. > I can't see how you move that back to the UI > without having duplicate data and a lot of issues. You talk about this as if it were a bad thing. Duplication of data is to be desired, especially in a distributed system, as long as there's some mechanism for assuring consistency. What we have a lot of is memory. What's potentially in short supply is bandwidth. The more we hold on to locally, the less we have to send around as data, if we've made up an adequately rich shorthand vocabulary. Jst as with the VFO example, the UI's notion of a VFO has very little in common with the DSP's and the hardware's, except a single number. The UI wants to remember that number. The DSP and the hardware don't need to remember it, they just need to obey the commands that effect it. I am unclear what advantage there is in any other arrangement. 73 Frank AB2KT _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
