--- a/doc/v2_planning/architecture_discussion.txt	Sun Sep 26 14:10:33 2010 -0400
+++ b/doc/v2_planning/architecture_discussion.txt	Mon Sep 27 10:59:00 2010 -0400
@@ -95,3 +95,18 @@
 problem, by having a special function that could alter the pipeline in some
 way (for example by introducing new components).
 
+OD comments: It seemed to me that one major issue we are trying to solve with
+these approaches is that of being able to interrupt an experiment, then
+restart it later without starting again from scratch. OB and JB's proposals
+handle this more or less automatically (compared to PL's that would require
+more manual engineering of the save/load process). However it is not obvious
+to me that they would necessarily make things much easier, because:
+    - One needs to use the same "framework" in all pieces of code (the +
+      syntax for OB, or a single program for JB), otherwise some manual
+      engineering will also be required. Can we reasonably expect the whole
+      code to adhere to this? (maybe...)
+    - If you want to be smart about what you (or rather do not) want to save,
+      it may add yet another layer of complexity (I'm not sure though how hard
+      it would be, so it'd be nice to have an example, e.g. if you are doing
+      K-Fold CV with the training set stored in memory, but you don't want to
+      save it on disk when serializing your experiment).