Questions about gnuCash backend access

[Derek Atkins]

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

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

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.

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.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available