[Synckolab] Thunderbird + synckolab + lightning = Replacement for Outlook

Niko Berger 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 
of clients


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  
> addressbook...
> 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
>> accordingly
>> 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
>> Niko
>> 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
>>> systems.
>>> - 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
>>> http://mozdev.org/mailman/listinfo/synckolab
>> _______________________________________________
>> Synckolab mailing list
>> Synckolab at mozdev.org
>> http://mozdev.org/mailman/listinfo/synckolab
> _______________________________________________
> Synckolab mailing list
> Synckolab at mozdev.mozdev.org
> https://www.mozdev.org/mailman/listinfo/synckolab

More information about the Synckolab mailing list