[EMAIL PROTECTED] writes:
> The plan is *not* to have this persist for any great period of time;
> it is, rather to build the whole set of transactions on the Scheme
> side and push them in at once.
OK, but then why have the c-pointers at all? Why not build a full
scheme data sctructure representing the properly massaged QIF data,
and then, once you're happy with it, hand that over to a routine that
traverses it, creating the C-side data structures as it goes?
Basically doing the same thing that the IO routines have to do when
reading from disk.
Further, if you're careful, your traversal routine could be the same
one we need to be able to read back in our scheme-form, text-format
data file. The only difference would be that when reading from disk,
the form reader can be incremental since (as I recall) the scheme file
data format is something like:
(account list)
(transaction (split) (split) (split))
(transaction (split) (split))
...
And when dealing with your QIF translation structure, you'll be
handing the function a giant list of these items (or similar). You
could probably handle both cases with two different wrapper (input)
functions to the same underlying parser function.
Bad idea?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
