It seems that I, and probably some others, got dropped from the list.
So I'm doing a big "catch up" and will remark on a number of suggestions
in this one message.
- - -
Linas suggested "plug-in infrastructure". I think that this is the way to go
in the future. This isn't really new or different, but more of an extension
of that which we have already started.
We could have basic sections:
1) A GUI,
2) GNUCASH LOGIC, and
3) DATABASE ENGINE
The important thing is to make sure that the interfaces between the sections
do not rely on "features" of a particular implementation of the section on
the other side.
WRT the 1-2 interface, I think we should strongly consider XML for the
interface language. That appears to be the solution de jour and many
development efforts are going in that direction.
- - -
A comment on SQL implemention of (3).
Some people think that MySQL is not appropriate because it does not meet the
"ACID" test. I, however, do not think that this is a requirement AT THAT
LEVEL. The "ACID" requirements can be moved up to the 2-3 interface and
deficiencies in the database can be shimmed in between for most users.
The typical "user" does not REQUIRE automatic fault correction mechanisms.
First of all, the need to use them is very unlikely to arise. Secondly, in
the typical "single user" usage, the cost of backing up and reentering some
data is likely to be less than cost of using a more robust solution all of
the time. Obvoiusly, there are some potential users who need the stronger
solution. However, I think that it is a mistake to deprive the masses of a
"solution" only because it is not perfect for everyone.
- - -
Bill Gribble commented on QIF files for bank statement reconciliation.
I think that in this case, we would want to have the bank's version "mark"
its transactions for reconciliation even if they were already in the database.
Linas seemed to say the same thing.
I think that the opposition is caused by the fact that our "reconciliation
model" is too simple.
We need to look at the JEs in terms of sets. The universe is partitioned in
multiple ways. For example, The "Accounts" form one partition.
"Transactions" form a different partition.
I content that we need to treat "Reconciliation" in the same manner.
Each JE should be assigned to a unique subset which corresponds to the
reconciliation document (bank statement). Entries that appear on different
documents should not be lumped into the same subset.
In addition, we can assign the unreconciled entries to different subsets
depending upon what we know about them.
In particular, it we download entries from the bank, we should flag them as
tentative members of the next reconciliation. That way, most of the entries
would be correctly marked when we open the reconciliation window and the rest
of the activity would be very simple to complete.
I think that it is imortant to be able to "unreconcile" some statement and
redo it. However, this ability may need to be locked out for periods that are
truly "closed".
