It's been a while since I looked at Mozilla Calendar, so this morning I installed the Firefox version and gave it another whirl. My first reaction was that this descendant of Netscape's calendar program must share a lot of DNA with the original -- it feels a tad clunky, UI-wise, in the same kinds of ways.
Like other iCalendar-oriented programs, such as Apple's iCal, Mozilla Calendar can use a WebDAV server as a poor man's calendar server. Feeling impecunious, I gave it a shot. Most of the how-to documents you'll find on this topic refer to Apache's WebDAV module, mod_dav. But other implementations will work too. IIS 6, for example, has a very nice WebDAV implementation. I had an IIS 6 box available and, now that version 6 has rehabilitated the tarnished security reputation of its predecessors, it was a fine choice.
Setting up a WebDAV directory in IIS is straightforward, as described here. Once you enable the WebDAV extension -- which, quite properly, is not on by default -- you just create a virtual directory and assign it the needed permissions. That, of course, involves the usual dance between NTFS permissions and IIS permissions. For the calendar user I created, those were:
NTFS: Modify, Read+Execute, List Folder Contents, Read, Write
IIS: Read, Write, Directory Browsing
Given this setup, I was able to publish my calendar from Windows Firefox to the WebDAV folder, and subscribe to it from two different OS X iCalendar clients, Firefox/Calendar and iCal.
Next, I checked the "Automatically publish your calendar" option on both of my Firefox clients and scoped out the situation. This is the "poor man's calendar server" configuration: initiating an edit on either client refreshes the calendar from the server, and completing the edit updates the calendar on the server.
A key feature of WebDAV is resource locking. I've seen some references to Calendar's use of it, but when I watched the protocol I didn't see any LOCK activity. The only WebDAV command I could see was a PUT to update the remote file. That's OK if I'm just trading my own calendar back and forth between several clients, but clearly you'd want to use locking if you want to have several folks publish events to the same calendar.
Because Calendar maintains a local copy of the file, it's possible to take your calendar offline. But it's tricky. You have to uncheck the "Automatically publish" option to prevent the program from trying to refresh from the server while offline. Now suppose you add an event, reconnect, and recheck "Automatically publish." On your next edit, the program will refresh from the server, and you'll lose the local change you just made. To prevent that, you'll need to manually publish the local calendar. Again, this is only feasible if you know that your local copy was the canonical version while you were offline.
Bottom line: this solution is workable, but not great. While Calendar could improve matters somewhat, it's ultimately just awkward to push whole calendar files around.
I wish there were a middle ground between this model and the dedicated calendar server. Imagine a WebDAV implementation that could map collections not just to whole-file resources, but to XML elements within files. Given an XML flavor of the iCalendar format, you could achieve more finely-granular control over calendar data. But the same model would work for other applications using other XML formats. And you'd have the option of searching with XPath or XQuery, again leveraging infrastructure not bound to any application domain.
I always envisioned WebDAV working this way. Maybe someday, when filesystems and XML databases merge, it will.
Former URL: http://weblog.infoworld.com/udell/2004/12/08.html#a1129