> This makes a lot of sense and seems very practical: > > 1. Fire up a CORBA server in the BBL and wait for calls from the MBL. > > 2. Call getOutput upon demand from the MBL to run a network (or > subsection of a network). > > 3. Call fetchInput upon demand from the PL to get input from a particular > node that may be remotely located. > > So, if I am with you so far, this just leads to a couple of questions: You're totally on the track so far. > 1. It seems like this requires that the MBL be smart enough to know that > it needs to split a network at display nodes, so that it can have access > to the results that need to be displayed. So if we we had Jean-Marc's > famous A->(B->C)->D network and say C were a viewer that needed to get > results, then the MBL would have to know to split the network here and > call getOutput on C (before calling on D), so that is could have the > output for display. Is this right, or am I way off base? If by "display nodes", you mean viewers, then I'll answer for the next question. > 2. I'm not sure how the Overflow *Probe will work under this system. Am I > missing something basic? You're right, they won't work! My "implementation" was only meant to include the basic functionalities, but for the probes/viewers, we'll need to add a sendMessage() and a distributeMessage() to the CORBA stuff in order to have communication between the DL and PL. BTW, there is no reason to do anything particular about the splitting for the probes. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01 at gel.usherb.ca