Apologies for the long absence. I've been traveling extensively as well as dealing a spate of family matters and other non-OSAF matters. I appreciate the continuing thoughtful comments and many helpful hints about getting the most out of IS X apps and Mail.app in particular. I don't think I'm going to be able to respond individually, so I hope this collective thank you suffices.

At OSAF, a huge focus at present in on making a series of decisions about feature priorities for Canoga. There have been many "Sophie's Choice" moments about which features aren't going to make the cut and will have to be deferred. Ruthless focus on nailing down design decisions continues to be at the top of my list.

I'll be speaking at the SDForum at 6:00 on October 23 on "Ubiquitous Open Source: What Does It Mean for the Software Industry?". The event takes place at PARC (formerly Xerox PARC) in Palo Alto. Details here.

Discounted admission $10 in advance, $15 at the door, if you mention you're part of the OSAF community of interest.

On my 15" G4 Powerbook, editing a Word document in Times 12 requires zooming to 150% to make it legible to my demi-century plus eyes (with my cheaters – without them nothing less than 30 point is any good). Times is a nice font for printing and 12 points is a good size to print in. But zooming up causes the spacing between words on the screen to be truly screwed up, rendering the manuever useless after all. I was befuddled until I started playing with fonts at random and found that Verdana 12 has a reasonable size on screen, so I've switched to it.

Why are most of the fonts, like Times, too small to read at normal point size? Does it have anything to do with the increased number of dots per inch on modern screens? Was Verdana designed to overcome this problem? Oughtn't there be a real fix?

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.