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 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.
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.
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.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
