Re: [Opensync-devel] akonadi-sync (discussion)

[Chris F. <cd...@fo...>]

On Mon, Sep 20, 2010 at 11:18:29PM +0200, deloptes wrote:
> I have also noticed (in the original code) that there was a hash table in
> use. The code needs to be rewritten, as Chris said, it is managed inernally
> by the library. 
> I had a look into the barry code and it also uses hashtables to manage the
> syncs. As for akonadi I'm not sure if it is required. I believe I read it
> can track changes of items internally. According osync docs a hash table is
> not required in this case.
> What can you tell me about this topic and the issue below?

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.

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.

I almost used the hashtable for google-calendar, but then I realized that
I would need to download all the records over the internet just to find
out what changed.  If your backend data source keeps track of what
was last changed, then you can dispense with the hashtable.

For example, in google-calendar, I store the date of the latest change
in a state_db key.  Then I ask Google what changed since then, and
create my changes from that.

The Barry plugin cheats a bit, and uses the dirty flags that are already
in the BlackBerry to tell what has changed.  It stores a counter in the
hashtable, and increments the counter for each item that is dirty in
the Blackberry.  In this way, the hashtable's logic still works (all
elements were "hashed") but no actual hashing had to be done.

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.

- Chris