On Mon, 06 Dec 1999 20:06:33 PST, the world broke into rejoicing as
Rob Walker <[EMAIL PROTECTED]> said:
>
> >>>>> On 06 Dec 1999 19:29:18 -0600, Rob Browning <[EMAIL PROTECTED]>
> >>>>> said:
>
> Rob> The problem with this is that there are cases that people have
> Rob> already discussed that require that the events be scheduled and
> Rob> run at a particular time even if gnucash isn't running then then;
> Rob> they must be asynchronous. Some of these events will be
>
> rats. is this one thing making it tons more difficult than it needs
> to be? if i could cat the gnucash files and _understand_ them, I
> would use standard tools and perl or sed or python or whatever to get
> it working. is there a simple format for gnucash that i could write
> with text tools, and then import it later?
No, there's not. I think there is considerable merit to the idea of
using a text-based format, for much the reasons you mention; it is
probably wiser for me to keep quiet about that 'til I do something
about it like writing a Guile script that can:
a) Dump all transactions in textual form, and
b) Read those transactions back in.
> Rob> Note that if we do get the locking/synchronization right, having
> Rob> both of these launched at the same time just shouldn't be a
> Rob> problem.
>
> ipc?
I think we've got here two issues:
a) Solving the "multiple processes working on the same data at the
same time" problem, which seems to me to be an *enormous* architectural
problem that is likely insoluble without very nearly a redesign of the
whole GnuCash engine, and
b) Solving the "queueing transactions" problem, which seems to me to be
a fairly simple problem.
The basic idea here is that we'd have a "transaction queueing" program,
"gnucash-q", which is a perl script looking like:
#!/usr/bin/perl
$DEST="$HOME/GnuCash/Queue";
$host=`hostname`; chop $host;
$date=`date +'%s'`; chop $date
$filename= "$DEST/tmp/$host_$PID.$date";
open(OUT, ">$filename");
# Now, parse the input data, whether commandline or stdin
# and turn it into the string $TXNBUNDLE
print OUT $TXNBUNDLE;
if (close(OUT) == TRUE) {
`mv $DEST/tmp/$host_$PID.$date $DEST/new/$host_$PID.$date`;
} else {
die "HELP!!! I'm broken!!!\n";
}
... And GnuCash, the "big process," would have a function that
would go through $HOME/GnuCash/Queue/new, taking all the transaction
files, loading them in, and then nuking the files.
You could have 40 processes concurrently writing to the Queue and so
long as they have different PIDs, hosts, or times, they'll not conflict.
Not even if /home/cbbrowne/GnuCash/Queue is being shared across NFS,
and those processes are distributed across 5 hosts.
The GnuCash "load-the-transactions" function would logically get
"spawned" upon invoking GnuCash, and would update the database for
anything that has been sitting out in the queue since GnuCash was
last run.
This does imply that the transaction queuer does not have the ability
to check balances. That is the "problem" with asyncrhonous queueing.
I would suggest that it's preferable to start with having async
transaction queueing, satisfy what needs are satisfied by that, and
then consider adding in a more synchronous scheme should that *actually
prove necessary.* Async queueing ought to be useful at least 90% of
the time, which is very much in keeping with the UNIX Philosophy.
--
DOS: n., A small annoying boot virus that causes random spontaneous
system crashes, usually just before saving a massive project. Easily
cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS.
-- from David Vicker's .plan
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
