Best way of sharing settings between concurrently open sessions these days?

2 replies [Last post]
Seb
Joined: Aug 14 2004
Posts: 18
Best way of sharing settings between concurrently open sessions these days?
Well, generally, I'm going to want almost all my SSH settings to be the same in all my SSH sessions... Likewise for non-MUD telnet sessions (which are going to be mostly Cisco ones). (I don't expect to have a lot though.) Is sharing the main session package(s) a bad idea? Is creating an SSH package and a Telnet package and then adding these packages to my other sessions the way to go? Is it better to open several instances of TeSSH, or just one with several sessions open? Bearing in mind several sessions will be sharing the some or all of the same settings at the same time. I would rather only have one TeSSH instance open as it uses less video memory or whatever resources I run out of on my work computer when I have too many windows/documents open... How are conflicts resolved between the sessions? E.g. Session1: I enable a setting, Session2 I disable it. Is it OK in Session1 until I close and re-open that session? Or does closing the session force a save, so it will be the other way around: Session2 will be OK until I close and reopen it?
Zugg
Zugg's picture
Joined: Jan 1 1999
Posts: 178
You should create a separate SSH or Telnet package and then add the packages to your other sessions. It's a bad idea to share the main session package. If you have several sessions open, it's probably better to just use a single instance of TeSSH. If Session A, B, and C all load the same "SSH Package" and you mark the "SSH Package" as Shared in the package preferences, then TeSSH will only load one copy of the SSH Package. If you started multiple instances of TeSSH, then each instance would load it's own copy of the SSH Package, and you could potentially have conflicts with different instances trying to save settings to the same SSH Package file. Also, as you mentioned, it would take less memory and resources to only have a single instance of TeSSH open. Conflicts depend upon whether you are using a Shared package or not. If the SSH Package is shared and you disable a setting in Session2, then it will also be disabled in Session1 (assuming the setting you disabled was in the shared SSH Package). If the SSH Package was *not* marked as shared, then TeSSH would load multiple copies of the package and disabling it in Session2 shouldn't effect Session1 (which has it's own duplicates of the settings). But again, then you might have trouble with these multiple copies of the same session saving the settings to the single SSH Package file. You wouldn't really know whether the setting would be enabled or disabled when you reloaded it, since it would depend upon which instance of the package got saved last. In general, if you have settings that will be different in various sessions, then those settings should be stored within the main session package. For example, put the common code and functions in a shared package, but then have individual aliases in each session that call the shared code. Then each alias can be enabled/disabled independantly. Closing a session forces a save, but saves are also done in the background on a timer while the session is open. So sessions are always saved, not just when you close them. Also, TeSSH can tell if a setting has changed or not. So in your example, if you change a setting in Session 2, and then save/close Session 2 first and then save/close Session 1 last, the value in the file will probably still be set to the new value set in Session 2. This is because when Session 1 saves, it doesn't detect that anything has changed, so it doesn't update that particular setting. That's why it's generally a bad idea having multiple copies of the same package open...you just never know which "version" will get saved to the single package file.
Seb
Joined: Aug 14 2004
Posts: 18
OK, thanks. I think it was helpful to get the current view on this, particularly in this forum for the benefit of users not familiar with CMUD, since a lot of the old discussion there may be out of date due to changes. My example was a bit contrived and I think working the way you suggest will be fine.