--- a/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt	Thu Sep 23 12:02:58 2010 -0400
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt	Thu Sep 23 12:10:14 2010 -0400
@@ -23,4 +23,25 @@
 
 I am not convinced that any of the stated advantages can't be achieved in more traditional ways.
 
+RP comment: James or anybody else correct me if I'm wrong. What I think James
+proposed is just a way encapsulating different steps of the program in some
+classes. These classes are serializable. They are not a programming language 
+per se. The way I see it is like dividing your program in a set of functions. 
+Each function is a control flow element applied to something ( like a CALL to 
+a python function ). The idea is to wrap this functions around something to
+make them serializable, and also offer the added advantage that you have a
+graph that presents the order in which you should call the functions and you
+can play with that order.
 
+That is why I was trying to convince James to re-write things ( using some
+syntactic sugar) to make it look less intimidating ( I believe it can look 
+much more "traditional" that it looks right now). I think a programming
+language might also be a overloaded term that so we might speak about
+different things. But if all that his proposal does is to offer some wrapper
+around python function that makes them serializable, and generate a execution
+order graph in which you can possible do simple operations ( like
+substitutions and replacements) I would not call it a programming language. 
+
+I think the advantage of making the program aware where in its own execution 
+flow it is and what is its execution flow can be quite useful for automating 
+some of the things we want.