StandardAbs (was: RE: dlpRecAttr* flags in pi-dlp.h)

[Robert Graham Merkel <rgmerk mira net>]

Vadim Strizhevsky writes:
 > 
 > Robert,
 > 
 > I think, you really want to implement the new conduit as
 > GnomePilotConduitStandardAbs, which current expense conduit is
 > NOT. The current version is GnomePilotConduitStandard which assumes
 > most sync responsibility onto itself. And current implementation
 > simply chooses to copy all existing records. StandardAbs however does a lot
 > of the dirty work for you. Take a look at memo_file or gnomecard (in
 > gnome-pim) conduits. You just need to implement several functions. The 
 > sync flags will all be set correctly automatically. And you can easily
 > ignore non new records in store_remote callback. which does pilot
 > record -> local record conversion.
 > 
 > -Vadim

Vadim, thanks for your help so far.

I've had a look at the memo_file conduit, and with the documentation
on the webpage I'm starting to figure out what's going on. 

I guess that GnomePilotConduitStandardAbs is a descendant of 
GnomePilotConduitSyncAbs, which is what's currently documented, given
the similarity of the signals, and it makes use of libpisock's
synchronization primitives.

pi-sync.h defines the four types of potential sync/copy operations as
follows:

* Erase all local records, and copy all remote records to local */
extern int CopyFromRemote(int handle, int db, struct SyncAbs * s);
/* Erase all remote records, and copy all local records to remote */
extern int CopyToRemote(int handle, int db, struct SyncAbs * s);
/* Synchronize local and remote using flags on remote */
extern int FastSync(int handle, int db, struct SyncAbs * s );
/* Synchronize by pulling all data off remote, and comparing to backup
   on local if flags show no change */
extern int SlowSync(int handle, int db, struct SyncAbs * s );

The synchronization primitives will NOT work, as I read it, 
as they assume that there is a local database containing a local copy
of the data.  This will not be the case, as the translation 
from expense tracker data to gnucash data will have to be strictly one
way.  Given several nasty hacks based on second-guessing how
the synchronization primitives do their jobs, it MIGHT be possible to
make it work without a local database, but I wouldn't like to have to try.

The CopyFromRemote primitive would only require that I hack the
store_remote primitive to only store new/modified records (by checking 
whether dlpRecAttrDirty is set).  However, if CopyFromRemote doesn't
reset the dirty attribute on the Pilot to "false" once the importation is
complete, I'm back where I started.

So, does CopyFromRemote reset the "dirty" attribute after being used?
Or do I have to keep a list of record ID's that I have seen so far and
ignore ones that I have seen?

I apologise if I'm going about things in a seemingly contrary way, but
the design of gnucash and my desire to keep things as simple as
possible sort of dictates this kind of method.

Thanks for all your help.

-- 
------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

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