DAViCal 0.9.8.3 - A return to stability
After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.
This release marks some significant departures from previous DAViCal. I've decided to walk away from some of the more ancient legacy software I tried to work with in the past (PHP4 & PostgreSQL 7.x), to move to support the most ancient-but-not-superseded legacy Linux release I know of, which is CentOS / RHEL, so DAViCal now has a minimum requirement of PHP 5.1 & PostgreSQL 8.1.
The biggest changes to DAViCal are under the covers. It is server software, after all, so the largest changes often are not visible on the surface. What has changed is that the architecture for constructing responses as been refactored into a core object which is used to access any DAV resource in the system. This greatly simplifies the general coding and reduces a fair bit of code duplication which had been happening. Another long overdue change is to get rid of the old arcane & obtuse permissions model, replacing it with something which will be radically faster in installations with more than a few hundred users, as well as being more consistent, easier for people to control, and directly in alignment with the DAV ACL specification. Some of the work here was assisted by NZ Registry Services who gave me a Macbook to help with my compatibility testing.
Not all of the changes are under the covers though. The new DAViCal also has a thoroughly revised administrative interface, and over the last couple of releases I've gone through the system trying to uncover all the places which were not properly localisable, too, so if you see DAViCal displaying strings in a language you didn't configure it for, it should be a fixable thing. I'd like to particularly thank Masahiro Mikami for turning around some Japanese translations very quickly which enabled me to quickly and visually see what was not properly translatable. There's still more work to do (there's always more work to do) but a fully translated DAViCal should, I hope, be quite usable by non-English speakers now.
The new DAViCal also supports some rather significant extra functionality beyond the CalDAV standard, in particular we can thank Rob 'Cave' Ostensen for providing an implementation of pub/sub event change notifications. This version also supports draft 2 of the proposed WebDAV synchronisation standard - that's still under development, but we expect to track pretty close to released versions of that.
Of course with all of this work there are some areas that didn't get changed. I didn't manage to finish an implementation of the scheduling extensions draft, much as I would have liked, but that is going to become very much a focus in the coming couple of months, and I'll be calling it "1.0" when things settle down after we get that done. Other things I will be working on include a ticketing system for providing targeted, controlled access to a specific collection or event, and making a start on CardDAV support for addressbook storage.
DAViCal seems to be fitting a need for people, and I know there are several thousand installations around the world, even if I'm not sure where they all are. I know some people are running DAViCal on their 8-way server, where I've no doubt it gurgles along pretty happily, and that there are some people running it on their OpenWRT installation, with some tiny amount of resources - just enough for a family calendar.
Traffic on the wiki has increased to several hundred thousand hits per month, perhaps three times what it was a year ago, and I hope that I can continue to provide a valuable and useful piece of infrastructure for that little calendaring corner of your organisation. What heartens me the most in this ongoing experience is the nascent community that appears to be forming around my software, with people writing 'tip sheets' and helping to answer questions on the IRC channel and mailing list. These small contributions made by many people - people whom I have never met, for the most part - are enabling me to put more time into feature development and expansion, and that's what I really love.