[Pipet Devel] sessions (was: we're back)

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> Okay, sessions then :) The newest cvs does just this--puts the info
> from each front started into a separate session and keeps track of
> them separately. When a front shuts down, the middle will
> automatically delete the xml associated with the session. When all
> fronts shut down, the middle turns itself off.

Great.  I like it.

> I know that later on
> people might want to leave the middle running all of the time, even
> without any fronts going (ie. if they wanted to be serving specialty
> loci to users at other locations) but for right now I just want to
> make it as clean as possible to start up and close Loci.

That's right.  We need to think of the middle as an Internet daemon.

> Why can't all sessions listen on one port? I can distinguish sessions
> over the same port based on the the connection, and properly
> communicate only with a single connection when multiple connections
> are fired up. Is there a performance issue here I should worry about?
> As I mentioned before, I've never tried socket programming, so I don't
> know about this.

Okay, I guess we're talking about Internet ports here, so it doesn't make sense
to use more than one.  My bad.  I was just thinking that we certainly want more
than one front-to-middle stream.

> > Okay, so the front remains locked up while waiting for a response.
> 
> Right--my idea is that the middle can also return errors to the front,
> so this way the front waits until the middle responds positively,
> before it goes ahead and visualizes a change in the GUI. Does this
> make sense?

Oh yeah.

> Okay, if we want to have the front listening on a different thread at
> all times then we'll need to have some kind of login dialog with the
> middle like the following:
> 
> Front asks to login:
> 
> <front>
>   <login>
>     <user name = 'brad'
>           password = 'encrypted' />
>     <session name = 'my_gnome_session' />

Session name or number?

>   </login>
> </front>
> 
> Middle responds:
> 
> <middle>
>   <success>
>     <port number = '12345' />
>   </success>
> </middle>

Very nice.

> Then the front will have to listen on this port for info from the
> middle. The session name gives the session a unique name so that other
> fronts could manipulate the same session. The user name and password
> provide protection for the session.

Excellent.  I was thinking that a front could tap into a session by providing
the session number/name on the command line:

    ./loci-gnome --session=3

(note, I want to change the name of front executables to loci-*)

>     So this could be done, but would require a login type dialog to
> begin a front. I think this is kind of overkill right now since we
> don't even have other fronts to start up :-) I think this is a good,
> and possible, idea, but should wait until things are a little further
> along.

Okay, no rush.

> Multiple middles would be a big pain, because we'd have to have them
> listen on separate ports to start with, and then would have to have
> some file or something where the fronts could find out what middles
> are listening on which ports.

We'll go with one middle then.

> I'd rather do things the way I described
> above, with a login dialog. Then the middle can generate all of the
> new ports while running, and pass the info back to the middle. This
> way, all fronts start off by talking to the middle on one standard
> well-known port, and then can subsequently be assigned specific ports
> if necessary. Does this sound snazzy?

Very snazzy.  BTW, what port number will we be using?  It's fixed, right?

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