[Synckolab] Thunderbird + synckolab + lightning = Replacement for Outlook
niko.berger at corinis.com
Thu Nov 15 01:45:42 PST 2007
Hmm.. there are other clients that support kolab-style folders (like KDE
Kontact) I dont know of any mac client, but you can always check out
http://www.kolab.org/about-kolab-clients.html for a pretty complete list
Edward Harvey wrote:
> Hey, a quick question for you -
> I recently decided for various reasons I'm not in love with
> thunderbird. Does this work with any clients other than thunderbird?
> I'm hoping for a Mac port ... compatible with Mac mail / Mac
> Thanks again....
> On Nov 12, 2007, at 6:38 AM, Niko Berger wrote:
>> 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
>> to choose which fields to take from which version (server or client
>> Through the options you can change this behaviour to "echo" from
>> (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.
>>> 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
>>> 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
>>> duplicates for Ben & Barbara.
>>> - I deleted the duplicates, and they keep coming back.
>>> Unfortunately, the "Synchronize" algorithm is the toughest to
>>> 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
>>> 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
>>> 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
>>> sync. The problem is a little tougher for thunderbird, because so
>>> users already have items in both containers.
>>> So the way I think best to implement something like synckolab is
>>> - 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
>>> 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
>>> automatically copy in both directions.
>>> - Once the initial sync is done, synckollab keeps a 3rd (private)
>>> 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
>> Synckolab mailing list
>> Synckolab at mozdev.org
> Synckolab mailing list
> Synckolab at mozdev.mozdev.org
More information about the Synckolab