Re: 0.1.43 memo conduit

[Vadim Strizhevsky <vadim optonline net>]

Eskil Heyn Olsen writes:
 > And how do we prevent this from happening in the future ? We can't rely on
 > people not deleting their stuff.

No we can't, and that was still a flaw in our current first_sync
implementation, as well as changing the local directory or file as a
destination. 

 > 
 > Brainstorming, haven't thought this stuff through ;
 > 
 >    The conduit's pre_sync is called.  
 >    It discovers an completely empty database.
 >    It sets a flags requesting "first sync"
 > 
 > 1) Sync is synchronize
 > 	then perform a SlowSync
 > 2) Sync is merge to/from pilot
 > 	then iterate over all records instead of new/modified.
 > 3) Sync is copy from/to pilot
 > 	Do nothing, solves itself
 > 
 > This would probably obsolete the current first_sync stuff.

I do like this, and while it solves a few cases that weren't handled
by first_sync, I think it introduces a new scenario that doesn't work:

Asume new way and without the first_sync stuff:

  1) User syncs with gpilotd (with memo_file) and all is upto date.
  2) User disables memo_file.
  3) Use syncs with Windows a few times and modifies some memos.
  4) User syncs with gpilotd (without memo_file) [SyncPC is reset]
  5) User enables memo_file
  6) User syncs with gpilot (with memo_file).    
	->PROBLEM: FastSync is performed, because local store is there
          allthough out of date and not all changed memos
          are picked.

This case is handled by our current implementation because step 5
would force the next sync to be Slow. Ideas? Maybe we need both, to
handle all the cases? Is this particular case important?

-Vadim