Cool! Note that the session data object implements the mapping interface, so you don't really need to pickle up a copy of it. I'd recommend against this, although it seems to be working well for you.
Any special reason why I shouldn't pickle apart from the fact that the ZODB will do it to save the object?
Instead, to save a session state, I'd just grab the current session data object and iterate over its items, grabbing things out of it that are interesting to my application. Then I'd copy these things into another data structure, maybe by sticking them into an instance of a class that also implements the mapping interface and put that instance in a folder somewhere which is related to the currently logged-in user.
Cool, I'll have to look at the mapping interface. I use a "fixed" version of UserInfoFolder to maintain a folderish object on each person, Im throwing this into there. Works nicely.
Then when a user wanted to restore a saved session state, get a list of session state objects in his session state folder, present them to him, have him select one. When he does, copy the items out of it into the current session data object.
The nice thing about this general strategy is that you can work with the current session data object in all of your app code that depends on session state. How the session state is saved and restored (and what the session data object values are) is completely independent of the app code.
Yep this is what I like. Im actually thinking this simple ZStore class is a useful little object for throwing stuff into, if I get mapping working I'll release the whole 50 lines of code it currently is... Thanks for your help. -- Andy McKay.