I've been using iCal as my principal calendar for a while now and have experimented with using its publish/subscribe and synchronization features.

iCal itself permits a calendar to be published, either to a .Mac account or WebDav server. In the case of the latter, it can be protected by a password. Once published, another client can access and download the calendar, either manually or on an automatic schedule (i.e. by subscription). Presumably the intent was to support publishing of calendars, e.g., sports teams or symphonies, such that people with an interest in the source could subscribe to the calendar to get its events automatically displayed on their own calendars. At the same time, while it has useful behavior for people who wish to share calendars with each other, which is a different use case and not, I suspect, the intended one, it also has a significant limitation.

One of the advantages of iCal's publish/subscribe feature is that it permits individual calendars to be shared. iCal itself supports having multiple calendars which can be overlaid onto a common display grid. So, for instance, Esther (my executive assistant) can maintain and publish my calendar, which I subscribe to. She also keeps her own calendar and does not publish it. She can see both her calendar and mine simultaneously, but I do not see hers, only mine, which is what I want. As far as this goes, that's great. The problem is that in the way Apple has done it, a calendar can have exactly one person with write access. I can read my calendar but I can't edit it. This proved to be unworkable.

Michael Toy told me that Apple's iSync program can be used to synchronize calendars via a .Mac account, so I tried it. iSync will synchronize not only iCal data but address books and Safari bookmarks. The presumed major use case is to synchronize data among several computers belonging to the same person, not to share calendars among a set of people. As with iCal's pub/sub, its usefulness for the latter purpose is mixed, excelling at something pub/sub doesn't do, but failing at something pub/sub does do.

In the iSync paradigm, one or more client computers register with the .Mac server. Once registered, client data is synchronized with the .Mac server, manually and/or automatically. Synchronization is a two way process, so participants can both read and write data. This is a key advantage over pub/sub. In practice, both Esther and I edit my calendar. I have not had a naturally occurring conflict, so my next experiment is to force a conflict to see what happens by changing the same event on two machines without allowing the first one to synchronize to the server and the server to propagate the change.

The disadvantage of iSync relative to pub/sub is that the unit of data synchronization is too coarse. It synchs all of the calendars (or none). So I get Esther's calendar, whether I want it or not. A system which combines the best of Apple's pub/sub and iSync would permit the selective sharing of calendars, address books, and other data sets, allowing read-only or read-write access (and of course do so in an elegant, simple fashion) would be a big step forward. As an added bonus, doing it without requiring involving a server would be a bonus.