QOF and portable devices

Fri Oct 8 17:33:06 EDT 2004

QOF translation matrix.

I've just come back from LinuxWorld Expo with a few ideas. 
:-))

(Some of the logic may not be sound!)

I've asked to join the Psion/Xios team to package Gnucash onto the new Psion 
prototype running Debian embedded - Gnome 1.4, Gtk, 2.6 kernel, already 
running gnumeric & OOo.. The current developers had commented that GnuCash 
would be a useful addition, so I volunteered. (Hope that's OK! - BTW, I'd 
like to exhibit GnuCash at the next one in 2005, would that be OK too?)

The likelihood of running GnuCash on a Psion raises the opportunity to make a 
truly generic importer for data in peripheral devices, not just my Palm and 
not just invoices.

1. Palm/Psion etc. can describe each of their databases/datasources to QOF, 
using a new compiled program / library / module that I'll work on. Extensible 
but start with only the objects required for invoices. (i.e. scratching my 
itch first!)

2. Where the Calendar, Expenses & Contacts applets are free software (Psion), 
QOF can be built into the applet as an export filter. With proprietary 
applets (Palm), QOF is built into a pilot-link conduit on the host machine 
that retrieves the data via HotSync. Both provide a QofBook in XML. The 
Palm/Psion QofBook uses non-GnuCash objects because the Palm/Psion knows 
nothing of GnuCash - to avoid dependency problems. GnuCash knows nothing of 
the Palm/Psion objects. A mapping program within QOF is the key.

3. GnuCash (or other QOF program), defines the objects internally, as now. 
To translate the data from one program to another, the QofObject data can be 
made available externally - stored in a default qofrc file in /etc/. I can 
easily write a program that will run in the same manner as a test program to 
write out the details from qof_object_foreach and other similar functions. It 
could be updated with each release. Each peripheral device, or any other 
program, defines their acceptable objects in the same way. It is the job of 
the translating program to determine how to pair up (map) the different 
objects as described in the file for each program/device.

(I did consider bringing the mapping directly into GnuCash. However, it would 
require the pilot-link/Psion code to duplicate their own mapping code to 
achieve the next bit.)

4. TWO WAY communication between ANY QOF process becomes possible. Basically, 
the Palm/Psion exports (even imports) a QofBook either directly or via a 
HotSync conduit. Is this worth the effort or is one-way sufficient?

5. The user then needs a program that works out the way to map one object to 
another - this can be user-dependent using ~/.qofrc.  Some of these mappings 
can be set by default. E.g. Calendar->Date == Invoice->Date_Opened.
(Calendar->End_Time - Calendar->Start_Time)  == Invoice->Quantity (with 
implicit setting of 'type' to "Hours"). Other defaults can be listed, e.g. if 
the user wants the day of the week or some expandable string for the 
Memo/Description field. The user sets things like the accounts  to use and 
this is stored in ~/.qofrc - each configuration step could even be done 
inside the relevant program, GnuCash would allow the user to specify the 
accounts to use and would store the GUID in the ~/.qofrc. No idea what format 
~/.qofrc would need to use - could be [ini] style or XML - probably favour 
XML. The idea is that this is a setup-and-forget operation - at least until 
new features are added to BOTH ends. All subsequent transfers only require 
user intervention during the qof_book_merge operation.

6. As originally discussed back in the days when I was thinking of XSLT/CSV, 
need to port the current GnuCash XML file format & parser to QOF for two-way 
transmission of QofBook structures in XML. Once the XML datafile is replaced 
by SQL, XML can be assigned solely to data interchange in this manner. 
Relocating the code from GnuCash to QOF is necessary for the devices to write 
a valid QofBook without re-implementing the current XML code (and thereby 
causing all kinds of incompatibilities in the XML).

7. Other supported PDA devices just need to install libqof, either on the 
device (Psion) or with a suitable conduit (Palm), to be able to communicate 
with any other QOF program on any device. Supporting any PDA device is just a 
case of creating a file to export the QOF and a descriptive file that 
contains details of all registered QofObjects for that device for use in 
setting up the mapping. As noted, mapping isn't at the object level but at 
the parameter level. A parameter from a Calendar object can easily be mapped 
to a gncInvoice object parameter whilst another parameter from the same 
Calendar object is mapped to a parameter in a gncCustomer object. If a user 
doesn't choose to setup mapping for any one parameter, it's simply not used - 
the user would need to edit the field manually.

8. QOF could even be a new standard for transferring complex data between 
processes.
;-)

METHOD.

qof_psion.c /* built into the Psion applet to convert Psion data into QOF */
qof_palm.c /* built into pilot-link conduit to convert Palm data into QOF */
Each defines the objects that are capable of receiving data.
As in qof_book_merge, only 2 way objects are accepted.
Each supported device needs their own qof_xxx.c program that takes the 
internal format and converts the data into a QOF export. All registered QOF 
objects in the export are then described in a qofrc file in /etc/.

qof_map.c /* the workhorse: maps QofObject parameters between QofBooks. */
(part of QOF, distributed in libqof, reliant on the descriptive qofrc files 
and creating a ~/.qofrc mapping file. Does nothing if only one set of 
descriptive files are installed. Accepts sensible defaults so that programs 
can provide examples. Most users should only need to specify user-dependent 
data like selecting an account name to store the GUID. Maybe another druid 
that loads the installed list of devices and a default map which includes 
some kind of placeholders for the user-dependent data? Run from GnuCash?)

To improve speed & efficiency, set the GUID retrieved from the QOF receiving 
program, (GnuCash), into the ~/.qofrc, ready for the next map and merge 
operation. e.g. to set the Income account and posting account.

(As far as invoices are concerned, I'll leave it to the user to post the 
invoice - I can't assume everyone posts invoices on a daily/weekly/monthly 
basis.)

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

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/20041008/0055ad34/attachment.bin