> > My question is, do we really need this level of control so that > > someone can manipulate a process so much while it is running? > > I for one am very much in favor of this level of control. As computational > biologists, we may be working on analyses involving terabytes of data and days > of calculations. Should the network just sit there unusable during these > analyses? Should entire jobs be scrapped if it turns out one node needs to be > moved? > > I think this level of control is akin to the use of threading in an > application. If threading is not used for compute-intensive tasks, the GUI > freezes up and the application is unusable. Sure, it's still running, and you > can always stop it. But the loss in usability is both perceived by the user > and quite real. > For all non corba techies: the DL (or gui) is corba based, this means the DL runs as a seperate application, and never freeses. Calling a corba function will always have a response, so it is the non-threaded corba server (the BL) that would freeze. This freeze will only take as long as the processing that corba call will take, being a few nano seconds. > > > For the following functions--do we need the processor to know about > > the description of the program? Can all of this type of information by > > stored in xml in the "middle scripting thingy"? > > This is mostly useful to the user and should be kept as XML meta-data. I > don't know what use the core has for it. The 'description' is merly a identification for the security meganism. > > The back-end or applications should set the status, which is reported back to > the user through the datastream. Also. But the DL must be able to modify the status of a node\subnet too. This wont happen too often, but things like renicing or stalling will be needed. > > Hmmm. I have been in favor of the GUI allowing only compatible connections > (same data type). If we assign types (e.g., mime) to data, we can determine > what will and won't work. The BL will be able to marchall (data conversion). This wont conflict with the type-casting the PL has, the marchalling will be like manipulating High-endian\Low-endian formatting, plain-encrypted formats, etc. > > > For the following, do we still need the processing engine to store a > > log/history of events, or should this be handled by the middle > > scripting part, which can maintain logs for all its communication. > > We can make a 'front' that records the datastream to a file. The BL (gms) already does this (see messaging_mobject_structs.h -> histryIO) But logging the PL nodes wont be touched by this. This should be optional, because logging every node will have huge CPU load.