Web interface for gnuCash
linux at codehelp.co.uk
Tue Jul 5 03:35:28 EDT 2005
On Monday 04 July 2005 8:46 pm, Christopher Browne wrote:
> > It's important that the data is merged rather than simply hacked into
> > the=20 existing storage. The user must have control over how any
> > conflicts are=20 handled.
> It seems to me that the only way it would be likely for a web interface
> to be plausible would be for data storage to be Fully and Totally moved
> into a full scale database system, e.g. PostgreSQL.
I disagree - that leads to all the problems of *forcing* one end to behave as
the other end expects.
"The problem here is that each program is limited to the shared backend. If
the user does not have this particular database (or any database) server
installed, the data is locked. "
We *must* avoid data-lock.
QOF is particularly good at providing the gopher between different front ends
and back ends. Linas, Derek and others designed it (when it was still part of
GnuCash) to be independent of front or backend code. It is and will remain a
core part of GnuCash, as fundamental as registers and reports.
GnuCash should not force a user to install or use one particular backend over
another. I don't want my data in Postgres, I want the choice.
> -> If data sits in files that sit inside the GnuCash instance,
?? The files don't become part of the instance. In particular, files that
contain QOF data are loadable by any QOF process. In most cases, these are
export files that are written out to a new file so locks are less of a
problem. Even so, QOF can use locks just like GnuCash.
> you need to have some portion of GnuCash up and running 24x7 as
> a "web server."
Bad idea. Wrong concept. QOF is a library that any process can use. Therefore,
the data can be stored by whichever process is using QOF in whichever folders
that process normally uses and once that specific task is over, the process
can quit. Far more sensible method of data handling because a system daemon
is NOT required.
There are far too many daemons already.
> -> Supposing data sits in some file-based storage system (e.g. as
> a set of XML documents, as is true now), or in some quasi-DB-like
> system like SQLite, multiple access points is a somewhat dangerous
> thing as they need to cooperate actively in order not to destroy
> the integrity of the data if multiple systems try to do updates
Please understand that this is the exact job that QOF was designed to do and
it can and will solve (has solved) the problems that you anticipate.
> Those problems are NOT resolved by migrating to some quasi-embedded
> database like SQLite; they would be resolvable fairly trivally by using
> a full scale DBMS as the back end, as this permits:
No, they are solved by using a middle-man - QOF.
> 1. 24x7 access; the database "server" is normally always up;
QOF is always installed and available like any other library but with the
crucial advantage that no daemon process is required.
Don't introduce a "single point of failure" like a central data-pivot in
postgres. If the server goes down or if the server cannot even be installed
for whatever reason, the user should still be able to use GnuCash.
You are in danger of proposing that GnuCash has a direct dependency on
postgres - that's a step too far.
I want to see GnuCash running on Psion hardware that cannot cope with a full
Postgres install - and neither should it have to!
> 2. Graceful handling of multiple concurrent users via transactions,
> ACID, and such.
Let that happen when the data needs to come together, not try to handle it
Different processes use the USER data in different ways. GnuCash will use bits
of it, other processes (like pilot-link) will add their own. Only when one
bit of data is needed from files created by another program does anything
have to be done for conversion.
Please try to see the wider picture of ALL USER data, not just GnuCash data.
GnuCash data is just one flavour of the wider all-encompassing "user data"
set. QOF provides a mechanism for each contributing process to access and
share data within this set. That is why it's so useful and why I'm working on
it to provide "open source data" as well as open source code.
1. Programs should make the user's data available to any process that requests
it. This data is free and the application has no rights over how it can be
2. Programs can use proprietary, binary or custom backends provided no data
essential to the re-creation of the original is omitted from the free user
1. Programs need persistent storage.
2. Each program is free to create their own storage methods and rules.
3. Users want to exchange data between programs.
QOF is a central mechanism to providing the kind of *user* freedoms that
*developers* have had since the creation of the GNU GPL.
We complained about M$ changing their (old) binary Office file formats to
exclude open source filters but then we do the same with our open source
applications by locking the data into the (open source) application!
Just because the *code* is open source, does NOT mean the *data* is open!
It is high time users got the true benefits of open source by having open
access to their OWN data.
We (as GnuCash) have no right to block how a user uses their data - to do so
would be to imitate the worst of the proprietary model. Instead, we should be
enabling the user to see and work with their data in open ways that retain
data integrity and work towards data freedom.
> Trying to hack the "graceful handling of multiplicity" into some
> middleware layer is likely to be way harder than biting the bullet and
> depending on a DBMS to Do It Right...
QOF is here to avoid the need for a database management program in the first
place. Take a look at the QOF homepage.
"QOF, the Query Object Framework, provides a set of C Language utilities for
performing generic structured complex queries on a set of data held by a set
of C/C++ objects. This framework is unique in that it does NOT require SQL or
any database at all to perform the query. Thus, it allows programmers to add
query support to their applications without having to hook into an SQL
It's a bit like a DBMS without the DB or M !!!
The best part is that it CAN use Postgres or MySQL or SQlite or XML or CSV or
binary or any other backend system. The key point is that is will NOT limit
the data to ONLY ONE of those. QOF uses backends as equals.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050705/1191947c/attachment.bin
More information about the gnucash-devel