[Pipet Devel] and still more infrastructure things

[J.W. Bizzaro]

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