![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
Changes between Version 4 and Version 5 of Session2
- Timestamp:
- Oct 1, 2015, 9:02:06 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Session2
v4 v5 5 5 From the user perspective, Chimera2 is an application with a suite of tools. In any given session, there may be some user data (e.g., molecules and volumes) and some active tools (e.g., Reply Log and Command Line). One of the required functionality of Chimera2 is to be able to save the current state of the session, and then resume the session in the same state at the future time. This sounds simple enough, but there are some details that need to be explicitly enumerated, as not everyone will agree what consists "the state of the session". 6 6 7 From the developer side, we can distinguish a couple different types of data. Some data are the same for all sessions; for example, start-up preferences and the list of installed tools. Some data are different for different sessions; for example, the list of _active_ tools and the currently opened data files. Let's call the former "initial data" and the latter "session data". Chimera2's "state of the session" consists only of "session data". This means that if the user (a) saves a session, and then (b) changes his start-up preference (e.g., background color) and it was not explicitly overridden in a session (e.g., by changing the background color), then (c) on resumption, the session will use the new background color. Clearly, this may be unexpected for the user. We will need to define what data normally defined by "initial data" that should always be saved as "session data" so that these surprises are minimized.(The answer is not "all of them" because clearly the list of installed tools may change, and additions and deletions cannot be ignored.)7 From the developer side, we can distinguish a couple different types of data. Some data are the same for all sessions; for example, start-up preferences and the list of installed tools. Some data are different for different sessions; for example, the list of _active_ tools and the currently opened data files. Let's call the former "initial data" and the latter "session data". Chimera2's "state of the session" consists only of "session data". This means that if the user (a) saves a session, and then (b) changes his start-up preference (e.g., background color) and it was not explicitly overridden in a session (e.g., by changing the background color), then (c) on resumption, the session will use the new background color. Clearly, this may be unexpected for the user. We will need to define what data normally defined by "initial data" that should always be saved as "session data" so that these surprises are minimized. (The answer is not "all of them" because clearly the list of installed tools may change, and additions and deletions cannot be ignored.) 8 8 9 9 (Chimera2 data can be categorized as raw data, GUI data, and organizational data. Expound.) 10 11 === Data Types === 12 13 All session data is simple, //i.e.//, int, float, string, list, dict, //etc.// or an instance of a class provided by a tool. 10 14 11 15 == Protocols == … … 31 35 == The Problem == 32 36 33 The problem is how to serialize the session state. 34 Ideally, when restoring a session, all data that is referenced by some other data has already been restored. Therefore all of dependencies need to be known by the saving code and there can be no circular dependencies. This avoids two-phase initialization, which is especially important for C++ objects. 37 The problem is how to serialize and deserialize the session state. 38 Ideally, when restoring a session, all data that is referenced by some other data has already been restored. 39 Therefore all of dependencies need to be known by the saving code and there can be no circular dependencies. 40 This avoids two-phase initialization, which is especially important for C++ objects. 35 41 36 42 === Where is Session State? === … … 55 61 * pseudobonds 56 62 * surfaces 57 * generic 3D graphics ( e.g.STL)63 * generic 3D graphics (//e.g.//, STL) 58 64 * atom/bond annotations 59 65 … … 85 91 * so some tools may need to saved before associated model 86 92 * does that mean that tools are saved first? 87 * ordering is complicated 93 94 How the data is organized in the session does not match the order in which the data needs to be saved. 95 88 96 89 97 === The Solution === … … 91 99 Circular dependencies are natural. So use two-phase initialization when deserializing a session. 92 100 93 Really don't want to use two-phase initialization for C++ objects. So don't. As long as the C++ objects are restored all together ( i.e., atomic structures and pseudobonds), we can avoid two-phase initialization for them. If the C++ objects refer to Python objects, that part would need to follow a two-phase protocol.101 Really don't want to use two-phase initialization for C++ objects. So don't. As long as the C++ objects are restored all together (//i.e.//, atomic structures and pseudobonds), we can avoid two-phase initialization for them. If the C++ objects refer to Python objects, that part would need to follow a two-phase protocol. 94 102 95 On the Python side, it is possible to provide an API that takes "simple" data and implements all of the individual save and restore steps. 103 On the Python side, it is possible to provide an API that takes simple data and implements all of the individual save and restore steps. 104 105 === Tool Classes === 106 107 * All classes exported by tools need to have a 'tool_info' attribute, a !ToolInfo instance 108 * !ToolInfo needs the State version in addition to the tool version 109 * When registering a tool's commands, it needs the !ToolInfo instance, just like starting a tool's GUI to be able set the the 'tool_info' attribute if there is no GUI 110 * The tool's module needs a 'get_class' function to return the class associated with a name. 111 * Tool classes might have an alternate initializer if attributes are not simple
