Carlos, Thank you for the e-mail and the GIF! Carlos Maltzahn wrote: > > I totally agree that Paos shouldn't shuffle around real data. I see the > role of Paos as a coordination tool but not as a database management > system. Yeah. I'm ironing out how I think Paos and XML fit into this project. It does appear that they are both neaded, being complementary. XML I think is best as manager for the biological data, while Paos is best as "guide" for the path taken. > 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, 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. > - 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. > - sends status information to a Paos server (e.g. processing started or > completed, or processing ran out of memory), > - receives notifications from a Paos server (e.g. "suspend", "abort", > or status query), > - queries a Paos server about where to send results to, Okay. > 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? > 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. > So I > would recommend sticking with Python objects for Paos communications but > use XML for everything else. > So Justin, do you agree then that our new XML should not include workflow information? The top of the XML, however, may still need an ID# to better track it through the system. ...and good luck on your exam this morning! I'm on spring break this week, which I'll use to get a bunch of things taken care of, including work on this project. Jeff -- J.W. Bizzaro Phone: 617-552-3905 Boston College mailto:bizzaro at bc.edu Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/ --