Compatibility between SIF-C, MS Outlook and Open Contacts

It is good to maximize the number of fields of contact data between devices. While SIF-C is the medium of exchanging info, the following fields defined in SIF-C were not implemented in "SifcToChangeLogXml.xsl" though it is not difficult to add them:

CallbackTelephoneNumber, CarTelephoneNumber, Categories, Companies, ComputerNetworkName, Importance, Initials, Language, Mileage, OrganizationalIDNumber, Revision, RadioTelephoneNumber, Sensitivity, Subject, TelexNumber, Timezone, Uid, YomiCompanyName, YomiFirstName

The Funambol Plug-in for MS Outlook needs to sync IM Address, and the plug-in add element "IMAddress" to the SIF-C package. Obviously SIF-C allows custom extension. So, "SifcToChangeLogXml.xsl" includes "IMAddress" to map to "Personal/IM" in Open Contacts.

The follow screenshot from testing shows that Open Contacts along with the sync client can handle almost every visual fields of MS Outlook Contacts.

Compatibility between address book programs for synchronization

Different address book programs have different way of maintaining name fields. For example, MS Outlook, Open Contacts and Plaxo have surname, given name, middle name and full name, while Mozilla Thunderbird maintains only surname, given name and middle name.

In addition, Open Contacts uses the combination of surname, given name , middle name and full name to uniquely identify a contact without standalone local ID, while MS outlook allow replication of such.

Most existing address book programs were designed to store people only. MS Outlook may handle organizational contacts through hacking -- those contacts without surname and given name is considered as organizations. Open Contacts clearly distinguish between people contacts and organizational contacts.

What SyncMLDotNet Will Not Do

Live Mesh

FeedSync

The development process of Plaxo sync client

I have been thinking of sync functions for long time, almost since the day 1 of Open Contacts project. I even contacted an European company which is specialized in developing sync programs for mobile devices.

Though I know it is not realistic for an one-man band to develop a decent quality sync solution, Open Contacts maintained timestamps for contact records since early version. Thus, the foundation of generating change log info was there.

Around half year, I found Plaxo had upgraded the service quite a lot, less disturbing, more powerful and convenient functions. In particular, the documentation for 3rd party developers is quite good. So I decided to give it a go to develop a sync client for Plaxo.

First, I upgraded Open Contacts to make it support timestamps for every data fields. This was found not necessary, as current sync solutions like Plaxo and SyncML would expected timestamps at record level, not field elvel. I would like to list some reverted attempts:

1. Used Delphi develop sync client. However, Delphi is short of Web functions and regular expression. Later I used C#.
2. The mapping for sync client used static Outlook fields to static Plaxo fields, and Open Contacts mapped static Outlook fields with dynamic fields. Later I used mapping between dynamic fields and static Plaxo fields, and Change Log XML used such format as well.

In last November, I released the first beta of OCPlaxoSync. The internal test results looked positive, and I am waiting for public response.

I am satisfied by the progress. I had thought developing sync solution is difficult, even if for developing the sync client only. I worked one to two hours a day on this project for around 40 days, building components one by one.

I used the following approach:
1. Build classes to represent Plaxo commands first, and use regular expression to parse command texts.
2. Build functions to convert XML to plaxo command objects.
3. Build web connections and Facade class, and test commands one by one online.

Such approach gave me self-testing framework, and I could understand and analyze Plaxo protocols gradually, while the progress of development could be made at the same time.

References to SyncML Specifications

The development was initially base on SyncML 1.1 Specifications. However, the schema of CTCap of Devinf elements is doggy. It is not consistent with all other elements, obviously a heritage of old school indent text tags, not friendly to XPath. Parsing CTCap 1.1 almost drove me crazy since it was not worthy to develop a complicated parser for this elements while all others can be parsed using XPath. Thanks God that SyncML 1.2 had updated the schema, now the schema of CTCap is quite healthy.

Nevertheless, I refactored the classes to make them conform with SyncML 1.2, now to SyncML 1.2.1.

The development is for PC base address book, thus, many of the specifications for mobile devices are not relevant. The following specifications were heavily used in the developments.

• OMA-TS-DS_DevInf-V1_2-20060710-A.pdf (Done)
  
• OMA-TS-SyncML_HTTPBinding-V1_2-20070221-A.pdf (Done)
  
• OMA-TS-SyncML_MetaInfo-V1_2-20070221-A.pdf (Done)
  
• OMA-TS-SyncML_RepPro-V1_2-20070221-A.pdf (schema, Done)
• OMA-TS-DM_RepPro-V1_2-20070209-A.pdf (with examples, Done)
• OMA-TS-DM_Protocol-V1_2-20070209-A.pdf
• OMA-TS-DM_Security-V1_2-20070209-A.pdf

DS Protocol Version 1.2.1
OMA-TS-DS_Protocol-V1_2_1-20070810-A This specification defines a synchronization protocol between an OMA Data Synchronization client and server in the form of message sequence charts. It specifies how to use the SyncML Representation protocol so that interoperating client and server solutions are accomplished.

SyncML Representation Protocol, Data Synchronization Usage Version 1.2.1 OMA-TS-DS_DataSyncRep-V1_2_1-20070810-A OMA Data Synchronization (OMA DS) is a specification for a common data synchronization framework and XML-based format, or representation protocol, for synchronizing data on networked devices. OMA Data Synchronization is designed for use between mobile devices that are intermittently connected to the network and network services that are continuously available on the network. OMA Data Synchronization can also be used for peer-to-peer data synchronization. OMA Data Synchronization is specifically designed to handle the case where the network services and the device store the data they are synchronizing in different formats or use different software systems.

SyncML Representation Protocol Version 1.2.1
OMA-SyncML-RepPro-V1_2_1-20070813-A This document specifies the common XML syntax and semantics used by all SyncML protocols.
OMA Device Management Representation Protocol Version 1.2 (1.2.1 not yet available)
OMA-TS-DM_RepPro-V1_2-20070209-A This document covers the Device Management usage of the SyncML Representation Protocol.

There are some elements not used in the OCSyncML projects:
1. Memory management.
2. Final