[Pipet Devel] and still more infrastructure things

J.W. Bizzaro bizzaro at bc.edu
Mon Mar 1 03:58:45 EST 1999


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

> 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"

> - 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,


> 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.

J.W. Bizzaro                  Phone: 617-552-3905
Boston College                mailto:bizzaro at bc.edu
Department of Chemistry       http://www.uml.edu/Dept/Chem/Bizzaro/

More information about the Pipet-Devel mailing list