doco updates

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@9376 57a11ea4-9604-0410-9ed3-97b8803252fd

src/doc/books.txt

@@ -349,6 +349,12 @@ Open Issues/Questions that Need Discussion:
 *) How to handle business objects? e.g. vendors, customers should be
    copied into both old and new books.  But invoices should be in one 
    or the other.  Need to document which is which.
+   Copy:
+   customer -- ok, has guid, has for-each
+   employee
+
+   No-op:
+   address -- do nothing
 
 *) Discussion Q: What should the naming convention be for the different 
    books?  When the XML file backend is used, different books need to be 

src/doc/constraints.txt

@@ -61,6 +61,24 @@ in an ad-hoc manner, with no governing framework.  This may change,
 as there is pressure to support more complex constraints that vary
 by region/country, by account type, by industry, etc.
 
+Why Not 'Lazy Evaluation'?
+--------------------------
+Lazy evaluation is supperfically like constraints, but differs in an
+important way.  With lazy evaluation, when something changes (e.g.
+the posted date) it is marked dirty. Later, when something else needs
+something (e.g. the posted date on a gains split), the dirty flag
+is examined, and, if dirty, the new/corrected value is computed and 
+returned.
+
+Simple/ad-hoc lazy evaluation works well when data dependencies are 
+simple, but it breaks down when there are too many/circular
+relationships.  It becomes all too easy to get trapped in inifite
+loops of corrections.   The goal of moving to a formal constraint
+system is to introduce specific, well-defined sync points where 
+constraint checking can be done, without incuring circular
+deopendencies.  At this time, the sync point is the xaccTransCommitEdit()
+subroutine.
+
 List of Constraints
 -------------------
 The following is a list of the constraints that are currently

src/doc/lots.txt

@@ -354,11 +354,6 @@ Quick API Overview:
    xaccSplitAssignToLot(): If a split is not already in a lot,
       then it places it into a lot, using a FIFO accounting policy.
 
-TODO:
--- need to recompute lot membership when source split 'amount' changes.
--- need to recompute gain value when source split value changes.
--- need to copy void status when source split date changes.
-
 Cap Gains Actual Implementation
 ===============================
 Cap Gains are noted by creating a separate transaction with two 
@@ -378,14 +373,27 @@ Things kept in sync:
 
 Things not kept in sync:
 -- kvp trees
--- description, memo,  other things?
+-- description, memo, action.
 
-The posted date is kept in sync using a lazy-evaluation scheme.
+The posted date is kept in sync using a data-constraint scheme.
 If xaccTransactionSetDatePosted() is called, the date change is
-accepted, and the split is marked date-dirty.  If the posted date
+accepted, and the split is marked date-dirty.  When the transaction
-is queried for (using GetDatePosted()), then the transaction is
+is commited (using xaccTransCommitEdit()), the date-dirty flag
-evaluated. If its a gains-transaction, then it's date is copied 
+is evaluated, and, if needed, the date changes are propagated/rolled
-from the source transaction that created the gains. 
+back on the appropriate gains splits.  Currently, one can only change
+the date on the gains-source transaction; the date on teh
+gains-recording split cannot be changed.
+
+TODO:
+-- need to recompute lot membership when source split 'amount' changes.
+   Done, need to test.
+-- need to recompute gain value when source split value changes.
+   Done, need to test.
+-- need to copy void status when source split date changes.
+-- when gains split is destroyed... ? the user did this intentionally,
+   and needs to scrub ... need to document that this is the users 
+   responsibility ... 
+
 
 Conversion
 ==========
@@ -463,6 +471,8 @@ Basic GUI:
 
    -- button or menu item, 'add notes to this lot'.
 
+todo:
+---- change lot viewer to use gnc-query-list
 
 
 Status