Books, sessions [was: Re: UI independance]

[Linas Vepstas]

On Tue, Apr 08, 2003 at 09:32:40PM -0500, Matthew Vanecek was heard to remark:
> 
> The way GNCBook seems to work now appears to
> me to be an amalgam of a Period and a Book.  That may have been
> intentional, but it's a little confusing at first.  What I was referring

The intent was to keep the concept of book and period separate.  A book
is a top level structure containing accounts, transactions, splits,
lots, prices, scheduled x-actions, and most (but not all) other things.
Books may be open for editing, or closed (read-only).

I was envisioning that someday there would be a 'period' object, 
that was a simple thing that defined a periodic interval (monthly, 
quarterly, yearly, etc., startig on the 1st, the 15th, the 2nd tuesday
of every third month, etc), and that this periodicity would be used to help 
determine when and how to close books.   

I don't know that a 'period' object holding this info needs to be a
first-class object; it might merely be a bunch of values tucked away 
in a KVP tree somewhere.  I prefer to reserve the first-class C objects
for things that have a lot of links and pointer chasing to them;
if its just some info it should go into a KVP tree.

> My understanding of the
> current (albeit incomplete) implementation is: You have a set of
> Accounts (a Book) 

Yes.

> which is active for a given and concrete amount of
> time (a non-existent Period).  

Uhh, books need not be closed at fixed 'concrete' periods of time.
Its up to the user if/when a book is closed.

> The chunk of time plus the set of
> Accounts equals a GNCBook.  

No.  Maybe you are confused by the fact that some period-type stuff 
is hanging out in the KVP structure for a book?  That's ony because
a book is a top-level structure, and so its a good place to hang 
top-level type info (Thus: top-level, 2nd-class objects are things
that would go into the KVP tree of a book)

> Conceptually, I'd rather have the two
> separate.  

yes.

> As we've discussed before, though, the Account cloning
> process is really the only logical way to implement it.

And that's how its currently done.

> I see that Lots have somewhat of a priority, so that should give me some
> time to recover from my hiatus from coding, and contemplate and confuse
> the situation some more. =P

Lots are a priority, since they were the stumbling block that prevented
periods from being implemented.  You cannot close a book without somehow
dealing with the  open lots in it,  since open lots represent 'unrealized
gains/losses' and are thus unfinished business. 

The current book-closing code should work fine (more or less) for
books that contain only ordinary bank accounts and ordinary income/loss
accounts.  Its the stocks & multi-currency things that trip it up,
and that lots were invented to solve.

--linas



-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933