[Pipet Devel] we're back

[Brad Chapman]

> 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

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

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

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' />
  </login>
</front>

Middle responds:

<middle>
  <success>
    <port number = '12345' />
  </success>
</middle>

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

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

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

Brad