I am planning to provide a web interface for GNU CASH. Need to know
the feasibility for the same. i functions which are right now
supported in gnuCash will be replicated on to the Web interface, and
will connect to the same DB as the thick client.
> Hi Dev Team,
> I am planning to provide a web interface for GNU CASH. Need to know
> the feasibility for the same. i functions which are right now
> supported in gnuCash will be replicated on to the Web interface, and
> will connect to the same DB as the thick client.
> Waiting your feedback/help/suggestions
On Monday 04 July 2005 6:09 pm, Derek Atkins wrote:
> I think it would be a lot of work to implement a web interface
> frontend for Gnucash.
Personally, I think it would be more reasonable to implement a data access
interface in HTML/PHP/Perl than to replicate the entire program. QSF could
help here - much like I'm planning on doing with Palm / Psion applications -
create an interface that can handle GnuCash data as QSF XML or just handle
certain elements, like creating invoices or transactions. This would parse
XML exported from GnuCash and then output modified XML that GnuCash could
merge back into the main data file(s).
It's important that the data is merged rather than simply hacked into the
existing storage. The user must have control over how any conflicts are
This kind of abstraction / separation is useful because it frees each program
to do what they do best without artificial restrictions on "it must do X this
way because that's the way GnuCash does it" which would inevitably result if
you tried to access GnuCash storage directly.
The reality is that a www front-end for GnuCash cannot work as GnuCash works.
It must work within the confines of the www interface itself. This sounds
obvious but the effects percolate down through the entire design. The more
you think about the design, the more you realise the subtlety of the changes.
QOF-generator is a start in this direction. There will be a Perl parser for
QSF XML and a PHP one will follow. That should allow any PHP script to accept
GnuCash data. Probably use some form of MySQL database for temporary storage
and cookies, sessions, etc., for data processing and then write out more QSF
This is purely theoretical at this stage, it's a nice idea and I'd support
anyone who wants to give it a go!
Derek is spot on, it could be a huge amount of work, depending on how *much*
of current GnuCash functionality is supported in the www data interface.
With the Palm applications, I'm planning on supporting existing open source
finance applications for the Palm and providing a QOF/QSF conduit via
pilot-link. The logic is already implemented and therefore my task is
considerably easier. Even so, there is virtually 0% chance that any of this
will be supported by the time G2 is released - more likely it will develop to
it's own timetable once G2 is out and my time becomes my own again!
> There is a lot of business logic in the UI.
> The "database" has no logic at all, it's just a data storage system.
This is the real challenge - handling complex GnuCash data within the
relatively simplistic handling methods available over www. Parsing and
exporting QSF XML would be the easy part. The particular difficulties relate
to how one object (like a transaction) is related to another (like an
account). This can be difficult to replicate outside C/Scheme.
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.