Better containerization of state to enable users to share everything

[markcmiller86]

A session file saves a lot of state but not everything. In many cases, what a session file saves is the equivalent of a pointer (e.g. a name) to a resource that is available elsewhere like a color table name in ~/.visit or a database name or a host profile either in one machine's install point but must be tweeked to use on another machine.

We need to be able to containerize (not to be confused with computing containers) all of the state essential for two users to fully share a VisIt session across systems that are not sharing any file systems in common.

[markcmiller86]

Other possible things to include...

• custom plugins (source would need to get compiled at recipients end)
• database files themselves (if very large, its a potential issue)
• expressions
• preferences
• environment variables
• color tables
• Python expressions or python command window tab contents
• macros
• the plot list of course with all operators, etc.
• state of global controls (e.g. auto-update...)

[cyrush]

Think we often have an opposite problem as well - the session file is too specific that the same person cant restore it on another machine without editing it. It would be good to outline a better approach.

I think this is tricky given the web of settings at play. Recall things like host profiles can contain per-user settings that won't work for another user (such as their username, or even banks they have access to)

If we want to make big changes, we might want to start with auditing cases where we need to "save settings" and restart VIsIt, b/c those will be barriers here.

[markcmiller86]

Maybe paraphrasing @cyrush here but better understanding of private (or maybe user-specific) vs. reproducible state would help here.

[JustinPrivitera]

I believe we decided that color tables should no longer have a home in the session files. This does make it harder to share state, but reduces bloat in the session files.