[Pipet Devel] we're back

[Brad Chapman]

> (1) Text case in Python scripts:
> 
>    Modules, methods and variables will use 
lowercase_with_underscores.
>    Classes will use InitialCaps.

Isn't this against the style guide for module names? It seems like the 
style guide says only allunderscores or FirstLetterCap style for 
modules, and I don't remember ever seeing a distribution that used 
underscores for module names. I don't really have a personal 
preference, I just want:

1. To be consistent with what other people are using (so that people 
will *want* to program on Loci and not be annoyed by the code).

2. Not to have to change again!

>        (b) Since the Web interface will start multiple middles (one
>            per Web user), fronts need to know which middle it is
>            plugged into.

The way I designed (well, copied the design of) the middle, a single 
middle can accept requests from multiple fronts. So we should never 
need to start more than one middle. Although this isn't finished yet, 
my plan was to have the middle start up a different directory to hold 
the workflow xml for each front that starts up. So if you started 3 
fronts on one middle (please don't try this yet :-), you would get 
three directories:

middle/temp/front1/workspace1
middle/temp/front2/workspace1
middle/temp/front3/workspace1

Each directory would be manipulated separately by its respective 
front. They will all communicate over one port on the localhost.
    If you want one front to be able to manipulate another front, this 
is much trickier. The way things work right now is that the middle is 
basically the slave of the fronts. It patiently waits for the front to 
call it, does whatever the front says, and then returns the 
appropriate info to the front. The front only listens to the middle 
when it is specifically waiting for a response. To have the front be 
continually listening to the middle so it can be manipulated will take 
more work (and more threads), and it will probably only be useful for 
using the NLI/voice interface to manipulate a graphical front. So I 
think it might be worthwhile to put this off a bit until things are 
smoothed out with this communication method.
    The way I'm going to try to get things to work right away is that:

1. Only 1 middle will run at a time (ie. if you try to start 2 the 
second one will not start).

2. The middle can handle multiple fronts (ie. process their xml 
separately).

3. If a front starts and there is no middle started, it will 
automatically start a middle.

How does this sound? 

Brad