ZMacSync - status

[dhns]

Dear all,
as already announced, we are working on a new Sync solution for the Mac (http://www.dsitri.de/wiki.php?page=ZMacSync).

This has triggered a lot of interested questions about a first release for testing.

Current status is:
* GUI is defined
* settings are preserved in the UserDefaults database
* ssh connection to Zaurus is being opened to run zdbat on the Zaurus
* Stickies are read into internal data structure on MacOS X
* iCal is partially read into internal data structure on MacOS X

To be done before first release:
* completion of parsing zdbat output into the same data structures
* error checking for ssh connection
* the sync core, i.e. comparing entries and decising which to copy where

So we are still away from a first alpha release which has at least basic functionality to try out. Currently the only things you could see are the user interface and error messages on the Console. So stay tuned...

-- hns

[dzins]

If you want some code that is basically a sync core and could be made generic that is currently used for the AddressBook, download the code for Zaurus Mac Sync from http://homepage.mac.com/dzins/helios

I would have said something earlier, but I didn\'t know about this user group.

If you are using Jason\'s original code, it deletes all of the AddressBook data and recreates it, so you lose anything that does not sync with the Zaurus (pictures, etc...).  The code in my updated version updates the Mac AddressBook instead of re-creating it every time and supports more fields.  The sync engine could be pretty generic in that it just compare the zaurus array with the last sync\'d array and the mac array with the last sync\'d array and then uses the sync master setting for conflict resolution.

Darwin

[dhns]

If you want some code that is basically a sync core and could be made generic that is currently used for the AddressBook, download the code for Zaurus Mac Sync from http://homepage.mac.com/dzins/helios

The code in my updated version updates the Mac AddressBook instead of re-creating it every time and supports more fields.  The sync engine could be pretty generic in that it just compare the zaurus array with the last sync\'d array and the mac array with the last sync\'d array and then uses the sync master setting for conflict resolution.

Darwin,
many thanks for this hint. I just looked over your code to understand what you are doing differently. Here are some of my findings:

My approach for ZMacSync seems to be a little more generic: I use the concept of a \"Bag\" holding objects of different classes, addresses, calendar entries etc. so that the only thing the sync engine has to keep in mind is that objects of different classes can never be the same or similar. This allows to extend the scheme to any type of data to be synced.

The other difference I see is that I have spent a single class per device, handling - and hiding - all internal data formats. So there is a class for MacOS and a class for the Zaurus hiding how to access the Zaurus as good as possible. Well, I have to pass in somehow the IP, user, password data from the interface.

The third difference is inspired by studying SyncML: there are basically 4 databases - one mirroring the last sync\'ed state of the Mac and the other of the Zaurus. The idea behind is that it allows to decode find out for each device independently which records have been added, replaced and deleted since the last checkpoint. I will think about whether I am doing too much here...

-- hns

[dhns]

The third difference is inspired by studying SyncML: there are basically 4 databases - one mirroring the last sync\'ed state of the Mac and the other of the Zaurus. The idea behind is that it allows to decode find out for each device independently which records have been added, replaced and deleted since the last checkpoint. I will think about whether I am doing too much here...

Found the answer: NO it is not too much. With three databases, the Mac and the Zaurus must be capable of storing all entries verbatim in the same way as in the third database. Otherwise entries will be repeatedly reported to be changed.

With four databases, it is easy to decode for the Mac and/or the Zaurus which entries have been added, replaced, deleted and just offer the other side to add, replace, delete as well. This is crucial for syncing more than two devices which will certainly have different capabilities.

So, ZMacSync will stay with the database per device concept - and I am just intruducing a plugin-concept for future extensions.

-- hns