Lionel Elie Mamane <[EMAIL PROTECTED]> writes:
> I would think that in principle having two schedulers in one program
> is wasteful and less maintainable than having one. My natural
> inclination would be to "generalise" the existing scheduler if
> necessary. I'll see when I'll get down to it.
Well, it very much depends on your definition of "scheduler".. It's
not that hard to write code that does, effectively:
for (i = list; i; i=i->next) {
foo = i->data;
if (need_to_run_p (foo))
run(foo);
}
> Well, I need to store the information "every 5th of the month, bill
> this customer that much, itemised like that". I'll see how this
> information is stored for scheduled transactions and go on from
> there.
I guess this all depends on how you decide to do this. First, the
date period can probably be completely re-used with the existing SX
code. So I dont think you need to define any kind of new storage for
that. As for "which customer" and "how is it itemized", that's going
back to my suggestion of "copy existing invoice" -- if you point a
base SX at an invoice instead of a template transaction then the
invoice itself can store all the necessary information about who to
bill and how. It does mean that you'd need to hand-bill each customer
once, the first month, and then set them up for repeat billing after
that.
Note that you cannot use the existing "template transaction", because,
well, it wont work (invoice != transaction).
>> Unfortunately you can't just make the SX engine call a "make
>> invoice" function
>
>> first, it would introduce a dependency loop in the code,
>
> ? I guess I'll understand this remark when I'll look at the details.
Basically the business code is all compiled after the engine code,
and the business code depends on the engine. If you add a dependency
a dependency in the other direction you now have a dependency loop.
The way around this, obviously, is a plug-in API. The engine has a
plug-in hole, and the business code registers and get's plugged in.
Voila, no more dependency loop -- because the engine does not depend
specifically on the business code.
>> and second we're trying to keep the engine completely free of
>> business code.
>
> I see.
This is a key importance. Right now you could remove all the business
modules from GnuCash and it would still run as normal. We do not want
to lose this feature.
> Lionel
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
