> 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