|
From: Emanoil K. <del...@ya...> - 2010-09-23 10:37:35
|
thanks
>
> The hashtable is there to track what changed in your data.
> For example, you might run each vcard through a SHA1 sum,
> and put
> the resulting sum in the hashtable. The hashtable
> would keep track
> of each uid and hash, and from the information you give it,
> would be
> able to tell you what has changed, and what the change type
> should be:
> ADDED, MODIFIED, or DELETED.
do I need a hashtable per objtype or per sync. By the way I think akonadi can take care of it, but still no time to check.
>
> One drawback of the hashtable is that all records need to
> be processed
> in order for its logic to work. There may be other
> ways to use it,
> but to my knowledge, the normal way is to run through all
> the contacts,
> for example, and hash them all. Then determine what
> changes to send
> to the engine.
yes this is not very useful for data over the net, but for local stuff it sounds to be ok.
And the statetable is used to store only changed states?? Again per objtype or per plugin or per sync
>
> If retrieving changes from akonadi is fast, or if you need
> to retrieve
> most of them anyway, a hashtable makes sense. If you
> can retrieve a
> quick table of changes, and know what uid's are dirty very
> quickly,
> then a hashtable can be used like Barry uses it.
> Otherwise, you'll need
> some other marker for what has changed since the last
> sync.
>
I almost got the changes, which means that now everything connects without error, though I'm stuck at that next level. I'll fight with it, though I'll be unavailable until next week.
Thanks for explaining! I think I have now much more complete idea of the process.
regards
|