RE: Making the expense conduit work with gnucash.

[Vadim Strizhevsky <vadim optonline net>]

Robert Graham Merkel writes:
 > 
 > 
 > I'm helping to develop gnucash (http://gnucash.org), a personal
 > finance manager in the spirit of Quicken.  I'm trying to add 
 > support for importing expenses from the Palm expense tracker into 
 > Gnucash.  
 > 
 > I have just downloaded gnome-pilot, compiled it without a hitch, and
 > have used the current expense conduit to read expenses.  From an
 > examination of the code, the current expense conduit simply
 > copies every transaction stored in the Palm outputs it to several
 > files.

Yes, that's true, but that's not necessarily how it should stay. There 
are several types of conduits. GnomePilotConduitStandard has 5
functions: "synchronize", "copy_from_pilot","copy_to_pilot", 
"merge_from_pilot" and "merge_to_pilot". Expense conduit is currently
an example of that, but it only really implements "copy_from_pilot"
logic, because it doesn't currently read the local store, which it
should to be a real conduit.

Instead I think expense conduit should be rewritten to be
GnomePilotConduitStandardAbs. This conduit already implements the
synchronization logic for all above 5 cases, and handles all fairly
completed syncing cases. All the conduit writer needs to do is provide
several functions that do simple operations like copy individual
records to/from pilot, compare records, etc... This is how memo_file,
gnomecal, and gnomecard conduits are implemented.

 > 
 > To import expenses successfully, it is necessary to guarantee that no 
 > transaction is exported twice.    Would it be possible to modify
 > the conduit so that only "new" (transactions that had not previously
 > been seen by the conduit) were exported, and then either deleted or
 > marked as "done" (either within the Palm or in such a way that the
 > conduit could maintain some kind of simple state knowing which
 > transactions it has seen)?

Well yes and no. Pilot knows what is new, and what is not, however
logic allways tries to keep the pilot and local store in sync, and I
don't think you want to go about deleting records on the pilot,
although that could be conduit option (and easy to implement too.)
What you will need to do is maintain local state, and have conduit
read in that file on initialization to know which records already
exist. It could I guess mark them specially in the file so that
gnucash ignores them on read in or something like that.

 > 
 > Unfortunately, such an operation would break the semantics of the 
 > conduit methods (it is neither a copy nor a merge).  Can the design of
 > gnome-pilot cope with this admittedly slightly unusual operation?

Well you could do this as well. I guess if this is an option on the
conduit that could be fine. But you should carefully consider what the
semantics of such "synchronization" would be. Especially when more
than one computer is envolved. But I guess it's just a matter of how you
want to use this.

Anyway for this to work what you want to do is implement your conduit
based on GnomePilotConduitStandardAbs as described above and all you
need to do is mark all existing local records as Deleted, and they
will automatically get removed from the pilot on sync, while any new
records will be created on the local store. if however person modified 
previous pilot record, than it will resynced to the local store, so
this one problematic case to consider what to do about.

Above basically delets all records from the pilot that were synced on
the previous sync. I can't currently think of an easy way to delete
records that are beeing synced on current sync, that would be kinda
hacky.

-Vadim