Web interface for gnuCash

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.

See http://www.data-freedom.org/
http://www.data-freedom.org/explain.html#database

"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.

> then 
>    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
>    concurrently.

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 
constantly.

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.

Data-Freedoms

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 
used.
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 
data.

First Principles.

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 
Database."
http://qof.sourceforge.net/

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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050705/1191947c/attachment.bin