QSF progress.

Neil Williams linux at codehelp.co.uk
Fri Jan 7 13:19:58 EST 2005


On Friday 07 January 2005 3:10 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > As this is in QOF, it doesn't use the GnuCash module interface used for
> > the current XML backend, but instead uses the load_backend_library()
> > routine:
> >
> > qof_session_load_backend(QofSession * session, char * access_method)
> >  load_backend_library ("libqof_backend_dwi.so", "dwiend_provider_init");
> >  load_backend_library ("libqsf-backend-file.so", "qsf_provider_init" );
> >
> > defined as:
> >  prov->provider_name = "QSF Backend Version 0.1";
> >  prov->access_method = "file";
> >  prov->backend_new = qsf_backend_new;
>
> I'm not sure what this means, but I guess it sounds ok to me.  We
> should probably just change everything to use gmodule anyways. ;)

Does gmodule refer to the GnuCash 1.8 method, a Glib method or the Gnome2 
branch?

This backend_library through QofBackendProvider is what Linas has setup for 
the DWI backend for QOF and hence that's how QSF will be built onto 
pilot-link and other applications - as an entirely QOF build. 

How is SQLite going to be built onto GnuCash? Are we using QOF or a direct 
bind? i.e. are gncCommodity and gncPricedb etc. going to be overhauled before 
SQLite or will the GnuCash QofBook still require additional, specialised, 
handlers? The 1.8 GnuCash file backend (via sixtp) uses secondary parsers for 
certain objects that are not directly readable via QOF - will this continue 
or will everything be read via QOF into SQLite?

Writing a QSF file from a QofBook was made very simple by only requiring one 
set of handlers. Book, object, parameters - 3 callbacks, 3 foreach loops and 
it was done. I'd love to see the same with GnuCash and SQLite - to me, it's 
the only way to have truly portable GnuCash data - it should all be definable 
through QofObject and QofClass.

>
> > I've got routines based on schema validation that can discriminate
> > between current GnuCash XML (bin, v1 and v2) and QSF XML, suitable for
> > use in gnc_file_be_determine_file_type and gnc_file_be_load_from_file or
> > elsewhere. The schema validation is used before loading QSF, before
> > writing QSF and in determining how to load the QSF (with or without maps)
> > - it's this that requires libxml2 >= 2.5.2 - and will mean that QOF will
> > never write an invalid QSF file and will bail out (with a few libxml2
> > messages and suitable QofBackendError values) if an invalid QSF file is
> > selected for import.
>
> Excellent!  Hopefully this can eventually also add the SQLite file
> format?

To determine the file type for all with one function? Yes. I don't know the 
SQLite file format but the schema validation will separate QSF from all other 
file formats. 

>
> FWIW, requiring libxml2 >= 2.5.2 shouldn't be a problem.  Even RH9
> (updates) distributes 2.5.4, and FC1 uses 2.5.11 by default.  So I
> don't see this as a problem.

Good. It's interesting that FC1 uses 2.5.11 - that could be useful for me with 
a secondary server that may yet be able to do test builds.

> > xaccAccountSetCommodity((Account*)ent,gnc_default_currency()); }
> > }
> >
> > void reference_parent_cb ( QofEntity* ent, gpointer user_data)
> > {
> >         if(!ent) return;
> >         if(xaccAccountGetParent((Account*)ent) == NULL) {
> >           
> > xaccGroupInsertAccount(xaccGroupGetRoot(xaccGetAccountGroup(targetBook)),
> > (Account*)ent);
> >         }
> > }
>
> I don't see anything particularly wrong with this -- except how would
> it deal with Scheduled Transactions, which have Account objects that
> don't live in the Book's AccountGroup?

SchedXaction.c doesn't define any QOF objects although the main struct does 
use QofInstance so currently, scheduled transactions are not supported by the 
merge code or QSF.

In order for a QofBook object to be accessed by either the merge code or QSF, 
the QofObject definition must have a create: and a foreach: definition and 
the QofClass parameters must include sufficient parameters to create a fully 
functioning object with only QofAccessFunc and QofSetterFunc. I'll look at 
that once I've got existing objects working fully - i.e. fixed this problem 
that shows up in xaccGroupGetNumSubAccounts.

-- 

Neil Williams
=============
http://www.dclug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- 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/20050107/e9a41e0e/attachment.bin


More information about the gnucash-devel mailing list