Stock "price" transactions

Rob Browning rlb@cs.utexas.edu
05 Dec 2000 11:58:57 -0600


Bill Carlson <wwc@wwcnet.nu> writes:

> Fine, except do you have any idea of when some of this support will be
> put in?  If I (and I suspect others) are going to realistically try
> to work on the new stuff, this is necessary.  

I'm signed up for this, and I should be getting started in the next
week.  I've already nearly finished re-working the "quote getting"
infrastructure to remove the need for swig, and finishing up that will
be my first priority after I get the new g-wrap stuff finished (which
should be in the next day or two).
 
> I would point out that one of the main reasons I use gnucash (or any
> such program) is to keep track of "where I am" financially (with
> history).  This means that eventually things like the account table
> gnucash shows on startup need to reflect the "current" value of a
> stock, and there need to be mechanisms to produce a history of that.
> I can do all that just fine with the current mechanisms.  Just want
> to make sure that whatever you are thinking of for this area
> reflects these "requirements".

Absolutely.

Oh, and you probably know this, but right now, 1.5 really is UNSTABLE.
In the past, you were pretty safe using it for real data, but right
now I would *highly* caution against that.

We may even change the XML format in a backward incompatible way,
though we'll obviously go be willing to go to some reasonable lengths
to avoid that inconvenience.

> One more thought on this.  Whatever "register" display you have for
> stocks should (I think) reflect the values of the stock at that time
> of each given transaction.  I think that means that if you don't
> have the "price transactions" the redisplay mechanism would need to
> consult the "price database" every time you opened/refreshed the
> "register" for the stock account.

Already thinking about that.  Actualy, the quote database is going to
have to be somewhat smart.  We're going to have to keep track of "why"
a quote's in the database.  For example, if you enter a stock
transaction, and you put in a price, the price will go into the quote
database, not the transaction, but the quote will have to know that it
came from a transaction so that if the user deletes that transaction,
or even if they just change the date, the quote in the database can be
deleted/updated as appropriate, and these "transaction quotes" will
need to be distinguishable from "historical quotes" (right now those
would be quotes obtained via the online-mechanism) somehow.

Again, thanks for your help and feedback.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930