A fairly common question that comes up in mailing lists and other forums is “Why doesn’t Entourage use the Apple address book?” I’ll give you my take on that here. As a disclaimer, I want to make sure it’s clear that this is my personal opinion, and doesn’t necessarily reflect the opinion of the MacBU, where I used to work. For background on the Address Book APIs, see Apple’s developer documentation here.
I’ll break down the problem into 3 levels of integration that could take place. First, I want to talk about the benefits of integration – they are significant. Having a universal address book means that you only have to manage a single contact list – you don’t have to keep multiple contact lists in sync and up to date. It also means you plug into iSync and can sync your contacts to any devices/services that iSync supports. You also get integration with other applications that build on the Address Book, like iChat. If you were writing a new application, you’d also get the additional benefits of not having to write a bunch of Address Book related code. However, in the Entourage case, we already have a rich contact experience backed by a powerful database.
The 3 levels of integration are:
1. Remove all contact related UI from Entourage and use the Address Book completely
This would mean we remove the address book tab from Entourage, and all of our contact related UI. When a user wanted to manage contacts, we’d have some entry point into Apple’s Address Book. On Panther, when choosing contacts, we could use the new People Picker dialog (confusingly, only mentioned in the reference section of Apple’s documentation). The advantage to this approach is that it gives the most UI consistency. We would use Apple’s Address Book APIs to do things like autofill when addressing messages. However, the Address Book application itself is not very extensible, so we’d have to loose a bunch of features including:
- Project Management (a huge new feature in Office 11)
- The ability to categorize contacts
- The address book fields we support but Apple doesn’t (there are a bunch)
- The ability to link to contacts to other items
- Custom views that include contacts
- Messenger integration
I could go on, but there are several show stoppers there already. I also believe that there is a lot of value to having everything in one app with a consistent UI.
2. Keep the Entourage UI, but talk to Apple’s Address Book database instead of the Entourage database
This one seems straightforward at first. The APIs support some simple database like functionality like searching (but not sorting?). It also allows you to put arbitrary properties on contacts. In many ways, this would be ideal because we could keep the Entourage UI with all of the fields we support, but still have that same data available in Apple’s Address Book application and to all other applications built on it.
However, there are lots of complications. For example, Entourage supports multiple “Identities”, where each identity has its own database and its own set of contacts. How would this work in this scenario? You’d switch identities, but have the same set of contacts available with identity? That would be really confusing.
And how would links of various sorts (including categorization and projects) work? Things could get easily out of sync because the user can independently swap the two database files. This will easily lead to inconsistency.
Also, Apple’s Address Book database is missing many features that would allow us to have the scalability, reliability and performance required. For example, in Entourage, when you look at the contact list, we only have the contact in data in memory for the contacts being displayed. This means that when you have 10,000 contacts, we only have to load in the 20 or so that would need to be displayed. With Apple’s APIs, I see no way to do this. We’d have to load all 10,000 contacts in memory. There are also no APIs to do optimized sorts. With Entourage’s database, we can very quickly sort the contact list on fields we choose to index (and others are slower). We can also do highly customized searches which are used for things like our address autofill and custom views. And, Apple’s Address Book does not support locking of records while making changes or atomic commits.
It would also be a lot of work to pull this off. Entourage’s code is built around the Entourage database model. Plugging in a different database, especially one so different would be a huge undertaking. We’d have to make major changes to the table code, the contact edit dialog, the AppleScript support, custom view code, and everything else that touches contacts. The opportunity cost would be huge.
3. Sync the Entourage and Apple Address Books
This is actually the solution I think makes the most sense. The basic idea is that Entourage continues to use its own store, but the contacts are kept in sync. This has all of the advantages of #2, except that there is some window when the stores may be out of sync. It’s orders of magnitude less work than #2, and you don’t have the disadvantages mentioned above. I’ll break this down into 3 options:
- Use iSync: One great advantage to this would be that we could apply the same work to sync tasks and calendars so you’d gain all of the benefits for those object types as well. The drawback is that the iSync APIs are closed L I think this would be the ideal way to go if it were a possibility.
- Write code in Entourage that syncs using the Address Book APIs: This is a reasonable alternative. We could be smart enough to know when things change in Entourage or the Apple Address Book to sync as needed, and only what’s needed.
- Wait for a third party to write one: This already exists! Paul Berkowitz has written an AppleScript solution available here. So, if you can download this today and the Apple Address Book and Entourage in sync for only $15!
I hope this clarifies the question for everyone. As I am now working on the people and groups platform in Longhorn, the tables have been turned on me. Now, I’m left wondering how 3rd parties will build on top of the solution we will be offering on Longhorn. This entry has already gone on far too long, so I won’t ponder that now.
[Update: Fixed link to Paul’s script. Thanks Dave!]