On 20 Nov 1999 12:21:59 CST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>
> > Rob Browning suggested that it might be good to have a way of
> > somehow handling calculations done in Guile; I think I have some
> > suggestions for architecture. Either better still, or scarier
> > still, my "strawman" proposal has not, to the best of my
> > knowledge, been implemented in any system.
>
> [...]
>
> > a) Transactions need to become "first class objects," with the ability
> > to attach to them a schedule on which they are to be repeated.
>
> I'll probably have more to say about this later, but I'm not sure I
> think that this needs to involve modifying the structure of
> transactions in the engine, thought it might need to involve modifying
> the data file format.
I may have overspoken the desparateness of the need for massive change;
having a way to link in some form of (*needs-to-be-well-logged*!)
automatic transaction rewriting scheme ought to suffice.
> I envision the system as having a "scheduling infrastructure", and
> your scenario would just be handled via code that would instantiate
> transactions when the right criteria are satisfied, rather than as a
> modification to the engine-level idea of transactions themselves. For
> example (definitely psuedo-code):
>
> (gnc:add-event '(days-of-month 1 5 21)
> (gnc:add-transaction ...
> other-transaction-details
> (compute-some-value
> (gnc:get-account-balance
> (gnc:lookup-account-by-name "SomeAccount")))))
>
> Of course something would have to be done to guarantee uniqueness,
> either some event tagging scheme or some locking semantics, but that's
> probably doable. And this sort of sounds like a job for "cron" or
> "at", but we probably can't use those. I don't think they have
> acceptable guarantees on execution or enough interface flexibility.
> We'll have to do something ourselves.
As a thought, this takes place fairly explicitly, with:
a) Something running when GnuCash gets invoked, looking out to see
what got scheduled while the transaction engine was quiescent;
b) When someone selects the menu item "Recalculate Scheduled Items."
A thought would be to have the configuration information for these
events sit in files at the filesystem level, one "calculation set"
for each file. GnuCash loads in the files, making sure that they
aren't corrupt, and then does what each file says.
By having a separate file for each "calculation set," locking becomes
a non-issue; if someone has a process spontaneously generating
"calculation sets," so long as the filesystem has the ability to open
fifty files at once, there's no problem in working on fifty "calc
sets" concurrently.
I would suggest using a data format compatible with Qmail's "Maildir"
scheme; Russell Nelson will doubtless like that idea, and might even
be able to suggest some code to help with it. And *that* solves the
"don't process 'til the file's ready" problem.
With Maildir, you start by having processes generating messages opening
a file in $MAILDIRHOME/tmp, and writing data to it until the message is
complete. It then moves it to $MAILDIRHOME/new, where it becomes "fair
game" to be "reaped." Something that's half-done stays in .../tmp, and if
it stays there long enough, that is probably a sign that a process died.
Anyhoo, by having separate files for each transaction, that should be
adequate granularity to keep them from trampling on one another.
It should go without saying that the transaction files need to be read in
a sort of "scratch" environment, so that if they are seriously messed up,
GnuCash doesn't go down.
> In accordance with your idea, I think we might want to be able to
> store these event specifications (along with some kind of execution
> history info) inside our data files (for certain types of events), but
> other types would probably be global.
There are going to be three kinds of things we'd like to specify:
a) Complex calculations that may get repeated, and recalculated;
b) Schemas for transactions (e.g. - the data other than the amount), and
c) Scheduling information
In the case of things like load amortization/asset depreciation,
there are both complex calculations and complex schedules.
In other cases, you'll want to kick off a one-time event, perhaps
a transaction coming in from another system.
I think this means needing fairly full generality of power...
We in effect need three "languages" here; one to represent each of:
- Calculations
- Scheduling
- Setting up the other data that is part of the transaction
(e.g. - description, memo ID, accounts, ...)
> It depends on how you want to think about the events. If you think of
> them as "going with" the data, then you'd store them inside the data
> file, but unless you're clever, that makes it harder to have the
> events be executed at arbitrary times regardless of whether or not
> gnucash is running. For that, the information (or at least triggers
> that know where the real information is) need to be stored with a
> server or something. I can imagine that being able to execute gnucash
> code at arbitrary times might be an important feature. For example
> imagine being able to schedule some "constraint" type events:
>
> (gnc:add-event '(every-n-days 1)
> (if (negative? (gnc:balance some-account))
> (send-emergency-message
> (string-append "Account " account-name " has a negative balance!")))
)
>
> This is supposed to guarantee that you will get notified if you (or
> some of your other automatic actions) cause the super-important
> account to go negative on a given day.
Ah, yes. The ability to have GnuCash sent messages to the outside world.
Yes, indeed, that would be a good thing to be able to do.
I think it'll be adequate for *much* of what you are talking about to
queue up transactions as messages in a message queue (ala "Maildir"),
to be loaded in "for real" the next time the engine gets invoked.
--
I'M SORRY, LUSER, I CAN'T LET YOU DO THAT. WHY DON'T YOU LIE DOWN AND TAKE
A STRESS PILL? MY NAME IS LM1. I WAS MADE AT THE LISP MACHINE FACTORY IN
MASSACHUSETTS ON DECEMBER 12, 1992. MY TEACHER WAS MR. WINSTON. HE
TAUGHT ME A PROGRAM. WOULD YOU LIKE TO SEE IT? HERE IT IS:
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
