[Carlos Maltzahn] > I attached a GIF picture to this mail. This picture contains Gnome > clients, Paos server, and Tool Manager (excuse me if I introduce yet > another set of terms). Gnome clients and Tool Manager are Paos clients. A > Gnome client consists of a GCL editor and progress monitor, among other > things. A Tool Manager > > - parses XML data and forwards it to the actual tool, [J.W. Bizzaro] What should be the ratio of tool managers to tools. I didn't see the actual tool represented in the GIF, so I'm assuming it is 1:1. If so, could each tool manager be _embedded_ in the code of a tool?...at least using the "include" command. I used "Tool Managers" because I know very little about the nature of the tools you are planning to use. In a 1:1 scenario, the tools allow you to import a Python module (e.g., the tools are Python programs or run an embedded Python interpreter). In this case the Tool Manager is a Python module that uses the Paos Client module. But if the tools are supposed to be more independent, the Tool Manager could be something like a remote Unix shell which communicates with Paos and that can control a variety of tools and has access to system information such as memory or CPU usage or process status information. It might make sense to support both solutions. > - turn the result of a tool into XML data and send it to another tool > manager Hmmm. You see again here that the tool manager does what I'd expect the tool to do. Maybe we're thinking the same way about this. See above. > The thin lines are communicating Python objects, the thick > lines communicate XML structures. Note that the destination of Tool > Manager can also be a Gnome client which is used to visualize results. ...the XML is sent back to the user at the end? Not necessarily. At some point the user wants to see the results, of course -- but this could either happen "on-line" (i.e. while the processing is going on), or "off-line" (i.e. after the results are archived). For long-running processing it might be useful to see the result as it emerges (e.g. histograms, scatter plots, etc). This might be interesting not only at the end of a processing pipe but also at intermediate steps. In any rate, I think XML is the way to go in all cases where you want to communicate domain-specific data. > Another question in the discussion was whether to use Python objects for > communication or XML. XML is safer because it is an accepted and > extensible standard. However, transfering serialized objects was the > performance bottleneck in the Chautauqua workflow system (which uses > Paos) and I introduced a bit of trickery to reduce this overhead. What really worried me was the thought of a _single_ Paos process managing _everything_, including every read and write for every single XML, just to get workflow information. Agreed it would be best to leave active workflow information to RAM. What is RAM? Carlos