Index: branches/eam_branches/ipp-20121219/ippToPsps/doc/upgrade.txt
===================================================================
--- branches/eam_branches/ipp-20121219/ippToPsps/doc/upgrade.txt	(revision 35073)
+++ branches/eam_branches/ipp-20121219/ippToPsps/doc/upgrade.txt	(revision 35075)
@@ -1,2 +1,28 @@
+
+2012.01.29
+
+I'm trying to re-work the operational model.  First, make sure we have correct names for concepts:
+
+* region : unit of spatial partition within DVO : a single region (eg,
+  n0000/0020.01) has bounds of lines of constant RA & DEC, and is
+  associated with 4 files containing dvo database tables for that part
+  of the sky.
+
+* batch : the unit of data sent to psps (1 camera-stage smf, 1 stack-stack cmf, 1 region-worth for obj, 1 init batch)
+
+* box: an area on the sky for which we are generating / have generated
+  batches.
+
+* config : an area on the sky for which we are generating batches in boxes
+  XXX : this name is somewhat confused & overloaded in ipptopsps -- it
+  encompases both the static configuration information and the
+  information about a processing chunk.
+
+* client : an instance of an ipptopsps running proccess
+
+Example sequence:
+
+* ippjython queue.py edit : create a new 'config'
+
 
 2012.01.27
@@ -7,10 +33,10 @@
 
   I need to change the way ippToPsps works at the operational level.
-  currently, the concept is that a 'config' is once and the boundaries
-  / aspect changed to trigger different processing.  this is poor
-  because it leaves no tracking, and it means the current situation
-  change change too easily.  in addition, the rules for triggering dvo
-  ingest are not completely clear, and probably not enforceable from
-  within ippToPsps
+  currently, the concept is that a 'config' is created once and the
+  boundaries / aspect changed to trigger different processing.  this
+  is poor because it leaves no tracking, and it means the current
+  situation can change too easily.  in addition, the rules for
+  triggering dvo ingest are not completely explicit, and probably not
+  enforceable from within ippToPsps for parallel DVOs
 
   alternatively, I'd like to have the following sequence:
Index: branches/eam_branches/ipp-20121219/ippToPsps/jython/config.py
===================================================================
--- branches/eam_branches/ipp-20121219/ippToPsps/jython/config.py	(revision 35073)
+++ branches/eam_branches/ipp-20121219/ippToPsps/jython/config.py	(revision 35075)
@@ -13,5 +13,4 @@
 class Config(object):
 
-
     '''
     Constructor
@@ -26,4 +25,6 @@
 
         # self.configdir is set in ipptopsps.jy on init based on env(IPPTOPSPS_DATA)
+        # for test purposes, an uninstalled system may use the config information from 
+        # a relative path
         if self.configDir is None:
           self.settingsPath = "../config/settings.xml" # TODO
@@ -35,8 +36,13 @@
         self.settingsDoc = ElementTree(file=self.settingsPath)
         self.logPath = self.settingsDoc.find("logPath").text
+
+        # XXX this is poor -- the czartool stuff is not related to
+        # ipptopsps and should be moved elsewhere
         self.czarPlotsPath = self.settingsDoc.find("czarPlotsPath").text
 
         # this is the border (in degrees) that we place around any loading box of 
         # PS1 pointings to ensure we pull a large enough area out of DVO
+        # XXX this is a poor place to put this information -- it is completely gpc-specific.  
+        # probably should go elsewhere
         self.BORDER = 1.65
         self.isLoaded = False