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. [Jon's Radio]