XML Size

[Christopher Hicks]

I'd like to add my vote for seeing things migrate to a data-access API
with a SQL back-end.  There are several advantages to this I see:

- With a data-access API folks could maintain the XML way of doing things
if they liked.  Nice clean API's make multiple implementations not only
less painful, but often it's quite helpful.  (Guido's recent comments
about the value of having multiple implementations of the python core
comes to mind.)

- A data-access API centralizes sanity checks and tends to make the
program easier to maintain and thus less buggy.

- An API provides an easy way to create a test suite to ensure that the
data is being handled properly.  Regression testing an API is much easier
than regression testing a GUI.

- additional applications.  This is initially just a programmer thing -
let me make applications where I don't have to learn/integrate them with
gnucash itself.  But obviously the end result would be a wider variety of
applications available.  The only "API" I've been able to find for gnucash
is importing QIF files.  There's certainly more potentially possible than
that!  There are other free-software accounting efforts out there.  I
suspect that gnucash's data API could become something like the Gtk for
accounting applications.  It'd be quite lovely for the gnucash front-end
and the SQL-ledger front end to be able to simultaneously access the same
data set.  [evil take-over-the-world laugh.]

A SQL back-end would have several major unique advantages:

- performance has already been mentioned, but I haven't seen anyone
mention the amount of effort it would take to replicate the technology
available inside any modern SQL server inside gnucash itself.  How many
times do we have to reinvent fire, the wheel, and indexing that doesn't
require programmers to think?

- replication!  This may not be the most important thing to everyone, but
I would /love/ SQL-level replication for gnucash.  I've had several
Windows machines crash losing or corrupting the main Quicken data.  One of
my own machines and several client machines have had the problem.  Most
had backups, but some didn't.  Real-time replication would be even better
than the Quicken-style backups.  The bandwidth requirements would be low
enough that I could run a machine at another site.

- multi-user!  Oh my!  This has been one of the biggest agonies with the
way gnucash currently works.  I had to setup a few scripts with lock files
to keep a few users from trying to use the same gnucash file at once.
This is certainly not an issue for the vast majority of users, but even on
my family finances, my wife and I would like to be able to dig into it at
the same time.  I have several clients that couldn't survive without
multi-user who would be great candidates for using gnucash for a variety
of reasons if it could handle multi-user.

-- 
</chris>

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
                                                        - - C.A.R. Hoare