Jan Schrage <[EMAIL PROTECTED]> writes:
> A much simpler, quicker and more reliable solution would be, IMHO, to
> leave the account database as it is and simply add a second database
> (i.e. structure in memory + file) containing nothing but the scheduled
> transactions for this account.
I agree with the general gist of much of what you suggest, though I
think your "parsing" concerns are probably easily avoided. If the
scheduling stuff (especially the IO) is handled from the scheme level,
then we get really solid parser for free.
> Indeed they haven't. Just think of somebody switching off his
> PC. cron will not execute any task that should have occured
> meanwhile.
Right. This was a primary concern. Though something like "at" is
more appropriate. All you need to implement any appropriate scheme is
the ability to register exactly *one* event with the OS that you're
guaranteed will execute at the right time if the machine is up, or
will execute when the machine comes back up otherwise. Then you just
register the "next time" you need to do something, and handle missed
events, etc internally.
> I also believe this is not necessary. After all, you do not need files
> that are changed at a particular date or time. First time you really
> need the change is when you next look at the files, meaning the accounts
> could be updated upon startup.
This is not sufficient. See my (and Christopher's, I believe)
previous comments on the subject.
> I think this, as well as the rest of your mail suggesting a server
> process, really implies that a computer be up and running all the
> time. For a number of gnucash users that will not be the case.
That's fine. Then those user's just can't ask for things that depend
on their machine being up. Though if I was going to enhance "at", it
would be an cool added feature to allow it to use the fancy "auto-on"
alarms on newer BIOSes to schedule the machine to come back up in time
for the next event :>
> Thinking of a client-server system means gnucash will be playing in
> a different league of accounting systems.
I'm just talking about a daemon like "at", not a real "finiancial
server".
> In that case I would also suggest moving to RDBMS for the storage of
> accounting information. Ah, well, perhaps we should stick to the way
> its going now at least for a while.
This has been discussed several times over the past year or so. See
the archives. The summary is that while some high-end users might an
an RDB backend, that doesn't really have anything to do with having a
good API on the engine, and if we have a correct implementation of
that API in our current engine, then we don't *need* an RDB for the
average user. Basically, that might be an option at some point, but
for various administrative and ease-of-use issues, it probably won't
be the default anytime soon.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
