On Sun, 2006-08-27 at 16:01 -0400, Frank Brickle wrote: > 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. > Distribution is transparent so I don't see that it make a difference if the nodes are distributed or not. Yes I was only considering the language integration to be local. Logically its a single node although the bulk of the work is being done outside of Erlang. The point was simply that under Windows you have to go through a socket connection albeit on the same machine to achieve that integration.
> 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. > I was only considering Erlang as the nodes with integration to another language where necessary within a node. I don't much like the idea of implementing an Erlang node in a different language as that seems to completely defeat the object to me. > > 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. It's not pretty though. These are exactly the integration issues I was trying to get away from. > > > 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. > It might be, but I want single language nodes or a clean way to integrate any language with the messaging infrastructure. > > ...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. > Ok. But something in this system has to be *the* application. If it's not the radio kernel (we seem to have introduced another term here, is this different from the VR?) and it's not the UI because that puts me back to square one where we have multiple UI's with screeds of code in them, then it's simply another node. Lets call it the Application Node for want of a better term. All the VR does for me then is slightly reduce the complexity of my Application Node. However I now need the ability for the Application Node to talk to the UI WITHOUT going through the VR which I think you would disallow from previous discussion. In fact most nodes like CAT for example would now want to talk to the Application Node and only the Application Node would talk to the VR. I don't think this is what you have in mind at all! > > 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. > Sorry, but I'm really unmovable on having a model. It's the central underpinning of the application and I certainly don't want to deal with data synchronisation issues. Quite honestly the data we are talking about going round the network is completely insignificant compared with the graphical updates. In fact another responsibility of my state machine is to pre-process the graphical data to just that which is required for the current state so it should reduce the total network traffic. It's been a very interesting discussion and I certainly haven't written off using Erlang but I will have to give the language integration issues a hard look. In the end I think we want different things. Probably best to carry on as we were and touch base further down track. I thank you for your time as I know all this interferes with the real work in-hand. 73 de Bob _______________________________________________ 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
