[Synckolab] Thunderbird + synckolab + lightning = Replacement for Outlook
niko.berger at corinis.com
Mon Nov 12 03:38:31 PST 2007
Edward Ned Harvey wrote:
> This is the core of the trouble I have right now: Given all the
> permutations of sync algorithms, it seems synckolab uses "combine"
Actually synckolab uses synchronize.. except that there is a bug that
prevents deletes (and thus renames - cuz renames are delete-adds)..
Still working on this :)
The algorithm used in synckolab uses an intermediate data store... I
already described it in the mailing list:
On every sync i will update an internal database, so for each entry i
can make the following decisions:
internal entry == tbird entry -> internal != imap entry ---> update
internal+tbird with imap
internal entry != tbird entry -> internal == imap entry ---> update
imap+internal with tbird
internal entry != tbird entry != imap entry --> ask what to do and act
For calendar there is actually already a nice interface that allows you
to choose which fields to take from which version (server or client side)
Through the options you can change this behaviour to "echo" from server
(disable the write to imap option).
So the behavior you are seeing is actually a bug and is being worked on
already see - https://www.mozdev.org/bugs/show_bug.cgi?id=17282
Dialog boxes like "XX is empty. Copy from Server/local?"
> - Synchronize: New and updated items are copied both ways. Renames and
> deletes on either side are repeated on the other.
> - Echo: New and updated items are copied from master to slave. Renames
> and deletes on the master are repeated on the slave.
> - Contribute: New and updated items are copied from contributor to the
> central repository. When the contributor renames something, the rename
> is repeated in the central repository. Nothing gets deleted from the
> central repository.
> - Combine: New and updated items are copied both ways. Renames and
> deletions are not repeated.
> Specifically, this is the behavior I am seeing:
> - I have thunderbird on a mac, and on windows.
> - I set up imap folder for addressbook, and set up synckolab on both
> - On the mac, I had Ben, Barbara, and Alex in my addressbook.
> - On the PC, I had Ben, Barbara, and Dave in my addressbook.
> - Both machines copied contacts to the imap folder, and I ended up with
> duplicates for Ben & Barbara.
> - I deleted the duplicates, and they keep coming back.
> Unfortunately, the "Synchronize" algorithm is the toughest to implement.
> Suppose there are two folders, A and B, and that a synchronization
> engine will periodically inspect these folders, to repeat changes on the
> other side. Then the synchronization engine must remember the way each
> folder looked, the last time it was inspected. The synchronization
> engine must keep a copy of A, and when it inspects A again, create a
> list of differentials to repeat on B. In fact, the engine must keep a
> copy of *both* A and B, so it can create a list of differentials for
> both sides.
> Fortunately, once an initial sync is completed, both A and B are
> identical. So it becomes redundant to keep a copy of both A and B. If
> the engine keeps a copy of either one, it in fact has a copy of both.
> Outlook is lucky they can avoid this problem - An initial sync is always
> done immediately upon first startup. So it's safe for them to treat the
> server as authoritative, and just do a download to achieve the initial
> sync. The problem is a little tougher for thunderbird, because so many
> users already have items in both containers.
> So the way I think best to implement something like synckolab is thus:
> - During initial configuration of synckolab, check both the local and
> imap containers to see which ones are empty. If they're both empty, the
> initial sync is already done. If only one is empty, just copy stuff to
> the empty container, and the initial sync is done. If neither container
> is empty, you have to prompt the user:
> ( ) Copy from local to imap (and delete whatever is already in imap)
> ( ) Copy from imap to local (and delete whatever is already in local)
> ( ) Combine local & imap, copy in both directions.
> - If you want to simplify the above process, it's not terrible to just
> automatically copy in both directions.
> - Once the initial sync is done, synckollab keeps a 3rd (private) copy
> of all the data, so synckollab can always compare the local vs
> last-known vs imap containers, to create mutual diff lists.
> Synckolab mailing list
> Synckolab at mozdev.org
More information about the Synckolab