[Pipet Devel] and still more infrastructure things

[Carlos Maltzahn]

    > 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.
    
    Okey dokey.  I guess in either case, though, the "tool" would lock up during
    communication...if communication were 2-way and it waited for a reply.

Yes -- but 2-way communication can also be non-blocking (and should be) --
this is the beauty of notification requests: "tools" can register
notification requests that are designed in such a way that a Paos server
can effectively query tools. This requires that tools maintain some sort
of event loop that periodically checks for events either from Paos or from
the actual processing. The Paos Client module supports multiple ways of
implementing this: (1) the Client module forks a separate process that
listens to the Paos server; upon receiving a notification it interrupts
the main process and forwards the notification to the main process (the
necessary signal handlers and pipes are all installed by the Client
module), (2) Client uses a pre-defined pipe to receive notifications; this
is useful if the application does its own event management, (3) same as
(1) but it assumes that the application has installed its own signal
handler (this is useful if the actual event processing is done in a
language other than Python).

    
    > It might make sense to support both solutions.
    
    I think so.  We'll have more flexibility that way.

A shell approach has the additional advantage of being more universal.
    
    > 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.
    
    ..."domain-specific data" meaning the scientific data.
    
Yes.

    >     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?
    
    :-) Random Access Memory, as in 64 MB RAM, system memory, not on disk.
    
Huh? What has physical memory to do with this?

    How's your thesis coming along?    
    
Thesis writing sucks! I wish I had more time to finish the Paos tutorial
(it's half done).

Carlos