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

Robert Graham Merkel writes:
 > 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. 

The documentation is a bit behind.

 > 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.

This is correct. My knowledge on the history and specifics of this is
a bit fuzzy. Eskil can probably provide more details on
this when he gets connected to the net again. However if I remember
the history correctly GnomePilotConduitSyncAbs is dead and libpisock
synchronizatin primitives are not used because they were lacking some
needed feature (or something like that, don't know
details). GnomePilotConduitStandardAbs however is very similar to it.

 > 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 );

We actually have 5 types. 

Synchronize : Record level synchronization as described by 3Com
Copy to pilot: deletes the entire DB on the pilot, inserts the local records.
Copy from pilot: deletes the entire local DB, inserts the pilot records.
Merge to pilot: syncs locally modified records, adds locally new records to pilot.
Merge from pilot: sync pilot modified records, adds new records from the pilot.

Synchronize actually could also be Fast and Slow depending on the
situation. You want to do slow if this first time conduit is synced or 
when the previous computer that palm has synced to is different. This
figured out automagically and you don't need to worry about it. 

 > 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?

Looking at the code I believe it does reset them. However I'm not sure 
I like this solution.

 > 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.

It's kind of very unnatural to the synchronization paradigm. In fact I'm
begining to think I should take back my earlier suggestion of using
StandardAbs for this (it will work with above hack but is correct
semantically?). Perhaps you better off doing it all manually similar
to current state of expense conduit,  except with the desired behaviour. 

How about if you have a special (user definable?) category (Unfiled by 
default?) from which all entries are added to gnucash and then
automatically moved on the pilot to a different category (Filed?). Or
perhaps optionally deleted. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]