A Closer Look at Sync Services
The Sync Services framework is based on a client (applications)/server (sync engine) model. The client(s) pushes data to the sync engine, the sync engine applies those changes to a truth database (a master copy of all of the information for the clients that use the Sync Services framework), and then the client(s) pulls the changes back.
The truth database and client processes reside on one computer and each user account has one sync engine and one truth database. The sync engine organizes and merges the data received from the many sync-enabled clients and stores this data in the truth database. The sync engine uses field-differencing to process changes made to records, as well as to discrete fields in a record.
There are several possible types of clients: an end-user application like iCal or a Cocoa app, a server application like .Mac, or an application that syncs a device like a phone or PDA. When a client registers with the sync engine, a property list file is created.
The client description, which includes schemas (Attributes, Data Class, etc.) and properties (
Entities, etc.), is stored in this file. The three Tiger sync schemas can be found in the
Clients communicate directly with the sync engine; clients do not sync with other clients or through another client's processes. Multiple clients can make push/pull requests simultaneously and faster devices can synchronize independently of slower ones. Sync Services supports a diverse range of clients and is meant to enable efficient syncing of user data: fast, frequent syncing of small data sets. Whole records are not pushed or pulled when only a few property values are changed.
This is called "trickle syncing." The process should be automatic, transparent to the user, and not require user intervention. Sync operations can be cancelled or postponed by the user, without data loss.
Developers can build sync-enabled applications in several ways:
- Adopt a schema that uses an existing data type. For example, Address Book or iCal.
- Extend existing schemas. For example, add fields to the system contacts schema in order to sync these special attributes across multiple Macs.
- Create a new schema for new types (sync custom objects).
The sync process involves five steps:
- Initiate a sync. Occurs when a client wants to push or pull data from the sync engine.
- Manage and negotiate the sync mode. A client can sync with the sync engine using several modes: slow, fast, refresh, push the truth, and pull the truth. A slow sync occurs the first time a client syncs. The client pushes all of its data to the sync engine, not just the changes. The sync engine creates a snapshot to compare future syncs against. Fast syncs will occur after this first time, with only changes passing back and forth between the client and the sync engine. A refresh sync happens, for example, when a client device is reset and all data is lost. A refresh request tells the sync engine to delete the client snapshot. The client then pushes no records and pulls all of the records still residing in the truth database. Push the truth describes the situation when a client wants to replace all of the data in the sync engine with its current records. Conversely, a client may want to replace all of its current data with the records residing in the truth database. This is called pull the truth.
- Push changes. A client can push either the whole record or just the properties where changes have been made.
- Resolve changes. The sync engine determines which changes belong to which record by using specific properties defined by the client(s) taking part in the sync. Unresolved conflicts are passed back to the user.
- Pull changes. Each client participating in the sync session gets only the data it needs from the sync engine.
You can view sync log files in ~/Library/Logs/Sync/ using either the default Console.app or, my favorite, BBEdit.
Sync Services in Action
Let's take a look at sharing an Address Book using .Mac and sync services. I keep track of not only my contacts but also my son Jack's contacts, because he's only eight and not a great speller (and I want to know who his friends are!). I enter his friends in a new group called Jack.
Once that's done, I can share out my Address Book.
1. Open Address Book Preferences and select the Sharing icon:
Figure 7. Address Book sharing
2. Check the "Share your Address Book" option:
Figure 8. Share Address Book
3. Add the .Mac user you'd like to share your calendar(s) with.
Figure 9. Add .Mac member
4. Use the Allow Editing option to give write access to your calendar(s).
Figure 10. Allow or deny editing
5. Send an invitation to the .Mac member.
Figure 11. Invite .Mac member
Back on the Mac mini, Jack confirms that his sync services are running, checks his email, and sees my invitation.
Figure 12. Email invitation to share my Address Book
He clicks on the link to subscribe to my Address Book and his iCal.app opens, asking if he wants to subscribe.
Figure 13. Calendar subscription confirmation
And ta-da! He can now look up his friends' email addresses and phone numbers through my published Address Book.
Figure 14. My Address Book in Jack's Address Book
Jack has a pretty busy schedule. I keep track of his activities, but want him to learn to be responsible for knowing where he has to be. To keep us both current, I set up a "Jack" calendar inside my iCal app, populate it with his calendar events and then publish it:
1. Open iCal. Highlight the Calendar you want to publish, go to Calendar in the menu bar, and select Publish.
Figure 15. Select a calendar to publish
2. The default calendar name shows up with several options to choose from. Click the Publish button to finish.
Figure 16. Publish the calendar
3. You'll get some information on how to subscribe to the calendar and how to just view it via a browser.
Figure 17. Subscribe and view information
4. There is also a button called Send Mail, which will open your Mail.app and prepare an email with this information. You only need to add the recipient email address(es).
Figure 18. Email announcement
When Jack receives the subscription announcement via email, he can choose to either view the calendar on the Web or subscribe to it.
Figure 19. View the calendar or subscribe
Figure 20. View the web version
Figure 21. Subscribe to the calendar
After he clicks on the Subscribe button, he can rename the calendar or leave it as the default. He can also choose to refresh the calendar at intervals and remove alarms and To Do items.
Figure 22. Calendar options
Jack now has a calendar that I keep current for him.
Figure 23. Jack's subscribed calendar