Changes between Version 3 and Version 4 of Session2

Timestamp:

Oct 1, 2015, 12:49:43 AM (10 years ago)

Author:

Greg Couch

Comment:

--

Session2

@@ -9 +9 @@
 (Chimera2 data can be categorized as raw data, GUI data, and organizational data. Expound.)
 
+== Protocols ==
+
+=== Saving protocol: ===
+1. visit all session state and record:
+  * what tool is responsible for the state
+  * what data it refers to and
+    * only referred to data needs to be named
+1. save the list of used tools
+  * need tool's state version, not tool version
+1. serialize state
+  * keep track of named data that was saved
+1. confirm that all referred to data was saved
+  * if not, then the session is incomplete/corrupt
+
+=== Restoring protocol: ===
+1. Read the list of used tools
+  * if installed tools are insufficient, then give user option to cancel or load tools
+1. deserialze state inside block/unblock of triggers
+
+
 == The Problem ==
 
+The problem is how to serialize the session state.
 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.
 
@@ -48 +69 @@
 * Can we provide a "simple" API for tools?
 
-== Part of the Solution ==
+== Possible Solution ==
 
-Saving protocol:
-1. visit all session state and record:
-  * what tool is responsible for the state
-  * what data it refers to and
-    * only referred to data needs to be named
-1. save the list of used tools
-1. serialize state
-  * keep track of named data that was saved
-1. confirm that all referred to data was saved
+Two competing solutions:
+1. allow circular references via two-phase initialization
+  * like Python's pickle
+2. Specify dependencies and save/restore in the right order
 
-Restoring protocol:
-1. Read the list of used tools
-  * if installed tools are insufficient, then give user option to cancel or load tools
-1. deserialze state inside block/unblock of triggers
+=== Example ===
 
+* molecular data needs to be saved early
+* molecular data is in a model
+* session gets a model from its list of models
+* a tool may provide a new model that depends on molecular data and tool state
+* so some models will need to saved before others
+* so some tools may need to saved before associated model
+* does that mean that tools are saved first?
+* ordering is complicated
+
+=== The Solution ===
+
+Circular dependencies are natural.  So use two-phase initialization when deserializing a session.
+
+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.
+
+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.