QOF and portable devices

[Neil Williams]

On Friday 08 October 2004 11:09 pm, you wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > 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.
>
> Sounds cool.

I've now got some QOF code available that works alongside pilot-link.
http://code.neil.williamsleesmill.me.uk/palm.html#CURRENT

It's only two objects so far, but it aims to provide QOF access to real PDA 
databases like address and expenses - vital areas of any invoice.

I'm hoping that the rest of the pilot-link team will accept these as a useful 
addition and then I'll work on the Calendar database.

With three databases covered, I can start on the mapping program / library.

So, my questions. (brainstorming really)

What's the best way to map QOF data from a PDA to GnuCash and vice versa?

Background:
1. The PDA will render it's data as a QofBook.
2. The PDA will have access to an XML backend.
3. The PDA QofBook uses different objects and the parameters need to be paired 
off against GnuCash objects.

------------------------------------------------------

Q1 : So far, I've only looked at QofBook's that contain the same range of 
objects - is there likely to be a problem when QOF is asked to retrieve a 
parameter from one book and set that data in another QofBook that has a 
completely different range of registered objects?

Will qof_object_foreach_type correctly identify which objects belong to which 
book? If not, if the object and parameter names don't conflict, is that even 
a problem? (I can use a namespace type arrangement to distinguish the 
objects.)

Should I look at creating two copies of qof_class_register? (no, preferably)
As long as each object definition is clearly identified:
        qof_class_register (PILOT_LINK_QOF_EXPENSES, NULL, params);
can the pilot link object definitions be separated from the GnuCash ones?

I anticipate that object/parameter name conflicts would need careful handling 
in advance, are there other traps?

------------------------------------------------------

Q2 : What format would work best for GnuCash for the expression of this 'map'?
(I'm asking a similar question on the pilot list too but they are all new to 
QOF.)

PILOT_CALENDAR_DATE <=> INVOICE_OPENED
etc.
(I'm using the original define here for clarity but it won't have to be 
represented that way in the map.)
The map is open to some user configuration but in many cases, a default map 
can be made available by all QOF compatible programs.

Each compatible program would simply export the currently memory-only 
qof_class_register to an external file, that would tell the map what each 
item means. Workable?

I'll then use the map to get the parameter on the left and (convert if 
necessary) to set in the parameter on the right (in the other book in the 
second QofSession). Using the same kind of process as the merge, with two 
books in memory.

Should I insist on both QofBook's being written to disk and using a separate 
program? (That's certainly the best test method, but what about later?)

------------------------------------------------------

Q3 : How should GnuCash communicate with other processes?

Could GnuCash accept modifications to the book already in memory?
(a kind of plugin - I know that would be non-trivial but is it achievable? 
desirable?)

It is quite possible that pilot-link will export the QofBook as a stream 
rather than a file and this could be piped to other applications. If GnuCash 
could listen to such a pipe, the invoice could be created with one step - 
just HotSync the Palm and it's done. (Just like with Kontact and other 
pilot-link aware programs).

:-))

(ambitious? Yes. Do-able? Desirable?)

What happens when GnuCash is or is not currently running?

Could a console mode program request permission to modify a file currently in 
use by GnuCash - perhaps using a form of the engine_suspend calls?

You never know, if we can get Quicken and Quickbooks to use QOF . . . 
(oooh, watch that little pig fly!)
:-))

-- 

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/20041021/61af6f4d/attachment.bin