Ths article by a Program Manager in Microsoft's Mac Business Unit gave me some new insights into OS X sync services. It illustrates how very hard it is to do synchronization of any sort between disparate products. Perfection is impossible, the best vendors can do is reduce the outrage rate.
Synchronization is Hell.
Andy Ruff includes a discrete link to
a section of Apple's developer documentation on the Sync Services Truth Database. To the bloodied sync veteran every word in these paragraphs could be written in blood (Entourage, according to Andy Ruff, defined a schema for Notes since Apple didn't have one. I find Apple's approach to schema definitions interesting.) ...
... The truth database contains an aggregate of all the client’s records. Consequently, the truth database uses a canonical schema that is an aggregate of all the schemas used by all the clients.
A sync schema is based on an entity-relationship model similar to that used by other Cocoa technologies. Read Cocoa Design Patterns in Cocoa Fundamentals Guide to learn more about entity-relationship models and terms such as entity, property, attribute, relationship, to-one, and to-many.
You can use one of the existing sync schemas—for example, for contacts, calendars, and bookmarks— extend one of these schemas or create your own. If you extend a schema or create your own, then you need to create an entity model for your custom objects and save it in a schema format that Sync Services understands.
This format, called sync schema, is a property list that specifies details about the entities in your model. For entities, you might specify the name of the entity and names of its attributes and relationships (collectively referred to as its properties). For attributes, you might specify the name of the attribute and its data type. For relationships, you might specify the name, destination entity name, cardinality, and delete rule. See “Creating a Sync Schema” for a complete description of the sync schema property list.
A sync schema defines a template for records stored in a database whose records are of a particular type (records belong to an entity) and may have relationships to other records. Records stored in the truth database are dictionary objects with key-value pairs, one for each property defined in the entity. Each record dictionary also has an entity name property and an associated unique record identifier. The record identifier is not stored with the record but is instead used by the client and sync engine when referring to a record. The truth database can also store custom fields in a record that are not defined in the schema. For example, these fields can be used to store client information added by a device.
The truth database doesn’t store arbitrary key-value coding-compliant objects—it stores record dictionaries. Therefore, unless all your entities are dictionaries, you typically transform records back and forth between the sync engine’s record representation and your client’s object representation. However, when fast syncing, you can apply changes only to properties—you don’t need to push and pull entire records when only a few property values changed.
Because the truth database is an aggregate of all the client schemas, it can contain a lot of information that your application doesn’t care about. Your client can filter the records that it pushes and pulls in several different ways...
The more I suffer with Apple's approach to Calendars, Tasks (phhhtt!) and Notes/Memos the more I'm interested in Entourage. The problem is there's no way for a 3rd party to sync directly with the iPhone Calendar. Microsoft would have to create a complete Entourage-friendly iPhone PIM suite, and I rather doubt they're going to do that.
Update: Macintouch has a great, meaning despair-filled,
thread on Entourage to iPhone synchronization. Synchronizing disparate data models is not a soluble problem. Even a deity-equivalent AI can't perfectly reconcile disparate data models.
