[Pipet Devel] and still more infrastructure things

[Carlos Maltzahn]

    [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