Re: 0.1.43 memo conduit

[Vadim Strizhevsky <vadim optonline net>]

Eskil Heyn Olsen writes:
 > On Sat, 20 Nov 1999, Vadim Strizhevsky wrote:
 > 
 > >   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?
 > 
 > This particular case would only occur if the HotSync under windows had the
 > same SyncPCId as gnome-pilot. And if we prevented people from setting it
 > (remove it from the capplet), and make sure we use a scheme unlike
 > HotSyncs, we'd be pretty unlucky if it happened.

Uhh, I don't think so. syncPCID are different. Notice the step 4.
This reequilibrates the SyncPCID for the pilot and gpilotd, but
memo_file didn't sync. So the next time it will sync it will do a
FastSync.

Am I missing something?

 > 
 > So I actually think we can loose the firstsync things and use this
 > instead. I'll think more about and also wait for comments.


Btw, firstsync might be useful for semething else entirely. If you remember
when you change sync options under Windows HotSync it let's you choose 
either a future default for a conduit or a one time action on the next 
sync. So you can do "first_sync=copy from pilot" and
"sync_type=syncrhonize". With proper gui support we could allow this
too with current implementation. And that's actually quite usefull
feature, me thinks.

-Vadim