Re: 0.1.43 memo conduit



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.

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

Wow, Gnome needs to have a AvantGo channel!

/dev/eskil
---



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