[Pipet Devel] we're back

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> > (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
                            ^^^
You mean alllowercase ;-)

> or FirstLetterCap style for
> modules, and I don't remember ever seeing a distribution that used
> underscores for module names.

You're right.  I thought the style guide implied that using underscores would
be acceptable, but it doesn't actually say that.  I was just thinking it would
be easier to remember 2 styles than several.  When in doubt, we should simply
read the style guide:

  http://www.python.org/doc/essays/styleguide.html

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

I meant 'one middle per Web front'.

> 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

Okay, I guess you're talking about different 'sessions' and not about multiple
fronts tapping into one session.  If this is so, perhaps you should have...

  middle/temp/session1/workspace1
  middle/temp/session2/workspace1
  middle/temp/session3/workspace1

and one port per session.

> Each directory would be manipulated separately by its respective
> front. They will all communicate over one port on the localhost.

My idea for multiple fronts 'listening' or 'tapping' into a single session,
allowed one front to control others.  If you're talking about multiple
sessions, shouldn't each session have its own port?

>     If you want one front to be able to manipulate another front, this
> is much trickier.

I guess you're about to answer my question ;-)

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

Okay, so the front remains locked up while 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.

It'd also be neat to have a gnome front manipulated by someone using Loci
through the web/web-interface.

> So I
> think it might be worthwhile to put this off a bit until things are
> smoothed out with this communication method.

Okay.  But what we're talking about is running the gnome front's GUI and
listening routine as separate threads.  I think it should be done this way, so
that we can have one front manipulated by others.

And I think you're talking about multiple sessions with one middle.  But which
would be more complex: one middle running multiple sessions or multiple middles
with one session each?  Multiple middles would give us the problem I mentioned
of the front (not) knowing which middle to choose.

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

Okay.

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

Multiple 'sessions'?  :-)

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

Uh-huh.

> How does this sound?

It sounds like a plan to me!

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+