QSF XML file backend for gnucash-gnome2-dev branch

Neil Williams linux at codehelp.co.uk
Tue Jan 25 11:38:21 EST 2005


I've got code in the patch just sent to gnucash-patches to correctly 
distinguish a QSF XML file from v1, v2 or the older binary GnuCash text 
formats and it loads using the QofBackendProvider mechanism rather than as a 
GnuCash module.

The patch includes the QSF schema for object and map files, it includes code 
to install the schema in a qsf sub-directory of $prefix/share/ and it also 
includes a test QSF map that will be the next phase of development to map 
pilot-link QOF objects into GnuCash objects.

Currently, the backend will load files but won't do anything else with them, I 
need to get a handle on the Gnome2 druids and add a qof_book_merge link. Not 
too hard, but I thought I'd submit the patch now so that the bulk of the QSF 
code is visible for everyone else to inspect.

The backend can cope with partial QofBooks and is designed to handle routines 
that create a second QofSession, populate that session with data for export - 
any QOF compatible objects - and save the session to export as QSF XML. There 
is absolutely no requirement for AccountGroup or any other specific object to 
be present, the backend will write out just invoices or just accounts, just 
customers or any mix.

Importing data will be done via a second QofSession, loading the QSF XML using 
qof_session_load which will automatically call qof_book_merge to control the 
merge into the existing QofBook in the original QofSession. I'll add File 
menu options for this in due course.

By QOF compatible, I mean:
Your QOF objects must have:
1. a create: function in the QofObject definition
2. a foreach: function in the QofObject definition
3. QofParam params[] registered with QOF using qof_class_register and 
containing all necessary parameters to reconstruct this object without any 
further information.
4. Logical distinction between those parameters that should be set (have a 
QofAccessFunc and QofSetterFunc) and those that should only be calculated 
(only a QofAccessFunc).

http://code.neil.williamsleesmill.me.uk/doxygen/group__QSF.html#ga15

QSF source files are included in src/backend/file and create their own 
library, gnucash/libqsf-backend-file.so

The patch also includes error codes and error messages related to QSF 
validation and parsing.

QSF increases the libxml2 requirement to 2.6.0 for the gnome2 branch to 
support the schema validation which identifies QSF files relative to existing 
files.

QSF uses UTC time throughout and uses this time format string:
#define QSF_XSD_TIME   "%Y-%m-%dT%H:%M:%SZ"

You can reproduce the string from the GNU/Linux command line using the date 
utility:

 date -u +%Y-%m-%dT%H:M:SZ

 2004-12-12T23:39:11Z

The datestring must be timezone independent and include all specified fields.

http://code.neil.williamsleesmill.me.uk/doxygen/group__QSF.html#ga87

I've got code that converts that back into Timespec and from Timespec to 
QSF_XSD_TIME - there is no need for any other part of QOF or GnuCash to deal 
with QSF_XSD_TIME.

Currently, the code supports these QOF types:
QOF_TYPE_STRING
QOF_TYPE_GUID
QOF_TYPE_BOOLEAN
QOF_TYPE_NUMERIC
QOF_TYPE_DATE
QOF_TYPE_INT64

as well as QOF_TYPE_DEBCRED as a QOF_TYPE_BOOLEAN currently. The parameter 
will be converted back during the creation of the QofObject concerned.

QOF_TYPE_INT32 is not a problem, QOF_TYPE_KVP is a little more of a challenge.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.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/20050125/8e191384/attachment.bin


More information about the gnucash-devel mailing list