Questions about gnuCash backend access

[Daniel Espinosa]

2007/8/26, Derek Atkins <warlord at mit.edu>:
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
> > 2007/8/24, Derek Atkins <warlord at mit.edu>:
> [snip]
> >> Agreed.  We really need a viable multi-user backend for GnuCash.
> >
> > What do you think is the BETTER way to do so?
>
> A GDA Backend.
>
> >> Having said that, GnuCash does not currently have a supported
> >> multi-user backend.  That WOULD be a requirement, so I encourage
> >> you to help Phil Longstaff complete the GDA Backend in the gda-dev
> >> branch.
> >
> > You say: "multi-user backend", but it isn't the same that a
> > "multi-user enviroment" , I think the solution is:
>
> I think it depends on your definition of "environment".  To me,
> I imagine a "multi-user environment" would be something like a
> small business office where multiple people need access to the
> same data file.  That's an "environment".  It has nothing to do
> with the actual implementation or coding; it's all a question of
> how the system needs to be used.
>
> A "multi-user backend" is a specific implementation.  It would be
> an upgrade of the old Postgres backend, migrating it from pure
> postgres to GDA.
>
> > a) Create a GnuCash Server a la Evolution, this allows any application
> > to use the GC's data, but this enviroment just allow connections from
> > the same computer and in a bussines software like GnuCash, you will
> > need to get multiple connections from diferent computers (the
> > accountant, the cashier, the owner, etc.)
>
> I don't think this is necessary, and I think it would be overkill
> for the vast majority of users.  It would imply a fairly major
> architectural change to GnuCash and I don't think the gain would
> justify the cost at this time.
>
> > b) Allow GnuCash to connect to a database server, in this escenario
> > each user will get a GUI frontend (actual GC's GUI) and will share
> > data with others using the multi-user enviroment by the dabase server
> > (this will be archived by the GDA backend), but it doesn't allow any
> > other application to use the GC's data and make sure it is using it in
> > the way GC does, keeping the data consistency and run the riquired
> > actions actualy in the GC's engine.
>
> This is required, and this is exactly what the GDA backend would
> supply.  This is why I'm pushing it so hard.
>
> > c) Allow multiple applications to connect to the GC's data by an API,
> > the data must be stored in a database server to get a multi-user
> > enviroment. With this any application can use the data in a consistent
> > way and doing just GC's engines wants to. As an adition you can allow
> > anyone to create the GUI according with its inviroment.
>
> We already have this now..  Someone could write an application and
> link against the gnucash engine APIs and then load and use gnucash
> datasets.  We would tie into a database through a GDA backend, just
> like we currently tie into an XML file via the File Backend.  There's
> no new coding necessary to get this working, it's all there right now.
>

BUGS! (please refer to bugzilla for details):

a) #470753 - There isn't any gnucash.pc file anywhere to export the actual API.
b) #470750 - The actual documentation talks about some non-existent
functions for gnc_book
c) #470755 - Add support for multi-user access
d) #470760 - Actual API doesn't allow to use GC's data

As you can see we need to fix them before to say "it's all there right now".

> > QOF dataset query engine is very limited and we want GDA give QOF with
> > the multiuser features GC needs, I think that GDA must replace QOF.
> > GDA can give us the same functionalities: datasets and queries, but in
> > a powerfull version, and the multi-user features required by GnuCash.
>
> This is arguable.  I've still never seen an application proposal that
> couldn't use the existing infrastructure.  You keep asserting over and
> over that you can't do it with QOF, but neither you nor anyone else
> has shown a concrete proposal for a real application that you intend
> to write that requires more than what QOF provides.
>

If an external application needs to access the GC's data must do it
using engine's API not QOF, then I found the following:

MORE BUGS! (please refer to bugzilla for details):

e) #470767 – Actual engine API doesn't export any function or gives a
way to get access to the QOF datasets and or create a QofQuery.

f) #470780 - Improve SQL support in QofQuery

Most of this bugs could be fixed using GdaDataModel and GdaQuery, and
inmediately access to tables, fields, rows or any object like triggers
in the database manipulation using GDA's GObjects.

I realy want Gnumeric or even OpenOffice, to get access to GC's data
and use their powerfull financial functions to get great financial
analisys, more sofisticated graphs, tendencies and more. QOF or
GnuCash doesn't allow give any method to share data with this
applications. GDA has some integration level with Gnumeric.

An applet will be usefull in order to help end user to quickly
register simple transactions without run GnuCash's GUI and at the same
time could show some graphs about your current financial situation.


> So, at this time I still don't see this as a short-term or medium-term
> goal.  It still feels like a solution in need of a problem, and it
> looks like a lot of work just to migrate from one dependency to
> another, for very little gain in the user experience or change in the
> API.
>

Yes may be is too much work, but I still think it could help the
progress of GnuCash from an Desktop Application to a feature rich
Bussiness Application.

If you can allow any external application to access the GC's data
like: applets, diferent GUIs (Qt, HTML), you'll get the end user more
than just a pure Gnome Desktop application. If you export the data by
a queried datasets with a powerfull set of SQL functions, any one can
create any kind of applications for financial analisys software for
personal or bussiness.

Today the possibilities are imposible to know becouse GC's doesn't
allow a minimum share level of data.

> I think you'd be better off, in the short term, migrating more object
> APIs over to Gobject, or working on the GDA backend with Phil.

Well I still wait for my patch to be applied to QofCollection (see bug
#453502) and wants to alling the current API convention to GObject's
one (see bug #470788).

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)