[...snip...my one paragraph summary of my idea...] Jeff wrote: > I thought communication (between cores) would occur in the brokering layer. > This is what GMS was going to handle, right? If communication occurs through > the Python-based definitions layer, what is the broker layer used for? It > must be used for more than communicating with Overflow (processing layer). Well, this is why I thought my plan was controversial, and not a simple summary :-) Although Jarl can probably answer this better, I think that the brokering layers primary responsibility will be efficient execution of nodes. This is what Jarl was proposing with his (really cool) neural net and genetic algorithms ideas. I think this will be really important since once you get complicated programs with long run times and intricate work flow diagrams, an important (and interesting!) question will be how to most efficiently execute the programs. The idea is that the genetic algorithms can learn from "good" setups and help users design setups--and I think this could eventually be integrated into your ideas of making Loci (now vsh) a development environment. So, my idea was that by having remote node communication occur in the definition layer, we could free up the brokering layer to do this kind of stuff. I think this will speed up processing times and make for a more efficient overall system (I had some arguments for these points in my first mail about this). Does this seem like an unreasonable proposal? Jeff wrote: > As an aside, we will eventually need a multithreaded connection between the DL > and the front ends. Well, this is another reason why I'm worried about using ORBit for everything. Not having any experience with designing multi-threaded corba applications, I really can't predict the kinds of problems we might see, or how well ORBit will handle multithreading on the level that will probably be going on in the definition layer. I guess this is an issue where we'll just have to try it and see :-) Brad