I've been working on implementing CardDAV support into DAViCal at the moment, and the first problem I encountered when I went to try and use it from iCal, was that the configuration on iCal didn't seem to want to let me enter a URL to my addressbook.

I've now released DAViCal 0.9.9, after five pretty intensive weeks of work. This includes a number of features that were implemented to support dotCal, which has now replaced their old Cosmo backend with DAViCal to break through a performance bottleneck. That turned into a six-week challenge, because Cosmo had wandered some distance from where calendaring standards are currently going, and so there was a lot of work under the covers of dotCal to switch from using various Cosmo-specific features to do the same thing, using open calendaring standards like CalDAV.

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.

I spent last week at the CalConnect XVI meeting of the Calendaring and Scheduling Consortium hosted by Apple Computer in Cupertino. I'd been hoping to get 0.9.7.3 released before I got there so I could concentrate on some of the more aggressive enhancement plans while I was there, but in the end I didn't manage to release until the Tuesday, during the event. Then, after some interaction with Kerio and a small but important bug that was found, I decided to release 0.9.7.4 with a very few small changes before moving onto the more radical enhancement plans I continue to work through at present towards a 0.9.8 release in a few weeks.

The release notes for both releases are on the wiki, including details of downloading and so forth:

• http://wiki.davical.org/w/Release_Notes/0.9.7.3
• http://wiki.davical.org/w/Release_Notes/0.9.7.4

At CalConnect itself, the first half of the week was an interoperability meeting which I was an observer at, though I did set up a server for people to test against, and the folk from Apple, Sun and Kerio were kind enough to test against this, including a very early version of the Symbian CalDAV client which is likely to be released sometime next year.

The second half of the week was a much more participative process, and gave me a much greater understanding of the general flow of the standards which are forming in the future. In particular it was interesting to get an idea of how close (or far away) the various nascent standards under development are. Some of the closest ones seem to be the Scheduling Extensions which is at draft 8, and will probably have only one or two more clarifying drafts before becoming an RFC. Next closest is probably the proposed CardDAV standard, and implementation of both of these in DAViCal is a priority for me.

The first thing I discovered too, was RFC5689, which is now implemented in HEAD and will be in 0.9.8. Another worthwhile standard, and relatively simple, is the Draft WebDAV Sync which is used by iCal4 if available, and which I have also implemented since leaving Cupertino. I expect there will still be some changes to the webdav sync specification, but it's relatively encapsulated so the effect of any changes are not going to be sweeping.

Support for the Scheduling Extensions for CalDAV, which I am working on now, will be more complete in 0.9.8, though probably still with a few missing parts. It is a large specification though it looks to be pretty stable now and is definitely time to move forward with it.

What the trip to Cupertino definitely showed me is that there is still a place for DAViCal in the available set of CalDAV servers. While there are starting to be quite a few around, and many are maturing nicely, there is still a niche for a free, standalone, SQL-based implementation like DAViCal and it is only through having a vibrant community of implementors around calendaring that we can flesh out the usable and useful standards that are continuing to come out of CalConnect.

Ultimately what impressed me the most were the people around CalConnect, who stand out as being a bunch of dedicated and thoughtful folk who really understand the importance of interoperation and open standards in this area. I do hope I have the good fortune to make it to another event at some point in the future.

Several weeks ago I was browsing around CalConnect wondering, as you do, if the timing will ever be right and the backing available for me to visit one of their meetings. It seems that the planets may actually finally be in alignment and I am really hoping that I can get to CalConnect XVI from 5th to 9th of October - though I will have to save my pennies.

In passing I noticed that the FREEBUSY Technical Committee has just published a Proposal for Freebusy Read URL, defining a bunch of optional parameters that can be used in queries against a freebusy URL. As calendar servers increase in power and scope it seems natural that these things will become more useful even if you might have thought time had passed them by, replacing them with more advanced CalDAV scheduling extensions.

Since DAViCal has always had Freebusy URLs, and in fact accepted a couple of simple parameters in them already it turned out to be a simple matter to provide these standardised ones as well. This change was included in DAViCal 0.9.7 which I released quietly into the wild a few days ago.

Today someone asked me to take a look at an Evolution enhancement that's just begging to get into trunk. Since this is a Gnome program in a subversion repository I've commenced the process of cloning the repository so I can look at the issue against the current head.

At the current rate I should have a copy of the repository by early tomorrow morning, in order to be able to start looking at it. Of course today is when I actually do have some time to spare, and I hope to be fast asleep at the time when I expect this to finish.

Presumably subversion isn't this slow for everyone, but since my latency to their repository is 300mS I'm probably on the worst end the pain, with each commit seemingly taking around a second. It sure would be nice if subversion provided some kind of chunked compression of these five-year-old commits, so I could be bandwidth limited, rather than latency challenged.

The addition of a day to the checkout of a software project must be a significant barrier to entry for anyone considering contributing. It makes it much less likely to be opportunistic.

So far I'm up to r3600 in 75 minutes. That's 75 minutes that I could have spent actually looking at the code, but now it's time for me to go and vote for me...

Well, it seems that there were few problems with the pre-release of DAViCal I pushed out last week, so 0.9.6 is out now.

The full release notes are on the wiki. The biggest change is that this release now supports free/busy using the method defined in the draft scheduling extensions for CalDAV, so it's possible to schedule meetings with Sunbird/Lightning or iCal, and possibly other clients if they support that.

Now I can concentrate on getting some paid work done for a few weeks before I start on the next stage.

Updated

After release I discovered that due to the changed behaviour of DAViCal, interoperation with Mozilla Sunbird/Lightning 0.8 was no longer working. A new 0.9.6.1 version has been released to resolve this issue.

Here are some pre-release DAViCal 0.9.5.90 (i.e. nearly 0.9.6) packages now. Since there is a lot of refactoring that has gone on under the covers here, I'll publish these packages so that people can tell me about all my embarassing mistakes, and I can correct them, before I upload them to places where they might get installed more or less automatically.

In particular if you do find problems with these, and can catch me on the #davical on irc.oftc.net during the coming week I should be able to include a fix into the real 0.9.6 release next week. If you can't get on IRC then an e-mail will also be fine.

The full release notes are here but the short version is that this fixes a number of bugs, notably one to do with importing calendars containing repeating events with exceptions. The big change is that this adds the initial support for the draft scheduling extensions to CalDAV, in particular the lookup of free/busy information.

Updated

In true pre-release fashion I forgot to actually enable the scheduling extensions stuff, so I've put new packages (0.9.5.91) on there now with that enabled... :-)

Finally, I have released DAViCal 0.9.5. Hopefully this will resolve the series of installation- and upgrade- related problems which plagued the 0.9.4 release.

Thanks for everyone being patient while this release was thoroughly tested through five pre-release versions, and especially thanks to those patient people who helped test those pre-releases.

Now if I don't get too distracted by:

• processing my GPS tracks of the last two weeks around the South Island
• Uploading my last six months worth of photos
• Making sure the kids have done their homework
• Describing the places near where I live.
• ...anything else that catches my interest

... then maybe I will be able to really concentrate on nailing the scheduling extensions work over the next couple of months...

Wish me luck!

Quite a few people seem impressed with the new release of Leopard, and are now looking for a CalDAV server to use with their shiny new iCal app. Unfortunately it seems that Apple wrote this primarily to work with their own (free, open-source) calendar server, which has the side effect that it doesn't work with DAViCal.

Part of the "doesn't work" is due to DAViCal not implementing some areas of the CalDAV specification, which is fair enough. Part of it is due to DAViCal not implementing some draft extensions to the CalDAV specification, which I can also understand, since it allows them to provide some useful features that those extensions are designed to support. There also seem to be some parts of the "doesn't work" which are due to a dependence on extensions beyond either of these cases, which is a little more disappointing - and quite a bit harder to implement.

So far I have made some fixes to the first point, and some additions towards parts of the second, but as of today it still does not work. This is complicated by my not having access to a Mac. Things are looking up, however, because Tom Robinson has kindly agreed to loan me a Mac running Leopard from next week.

In order to "clear the slate" for that, I will be releasing a 0.9.2 over the weekend with the various minor enhancements and fixes that have been applied over the last week. So although this upcoming release will let you add your DAViCal account to iCal 3, it still won't actually work with it. I'm hoping that ready access to the application will enable me to correct that fairly quickly.

Also waiting in the wings (and which unfortunately won't be in 0.9.2 either) Maxime Delorme has been working on SyncML support, and is nearly ready with a patch, so we can look forward to that addition fairly soon also.

I have not been able to put a lot of effort into DAViCal over the last couple of months, since my father was diagnosed with stomach cancer in early September, and he died on 2nd October.

So here it is, finally, including a lot of refactoring work around the handling of DAV/CalDAV REPORT requests and implementation of the DAV::principal-property-search report. This also requires an upgrade to the latest AWL library (0.20), which includes a complete rewrite to the class used for parsing and rendering iCalendar data.

This release is recommended, since you will need some of this stuff to support the upcoming Mozilla Calendar 0.7 release properly.

At this point I have only released the files to http://debian.mcmillan.net.nz/ and I'll push it out to a wider audience if I don't here screams of anguish from people in the next few days :-)

This release does not have any associated database changes, so it should be a simple matter to install the upgraded code.

After much wading through possible names, none of which really excited me, I have finally chosen "DAViCal" as the new name for my CalDAV server that was previously called RSCDS, or the "Really Simple CalDAV Store".

In the end, I chose DAViCal because it:

• seems easy to pronounce.
• combines the 'Cal' and 'DAV'.
• returns < 1000 results on google.
• doesn't make me cringe.
• didn't have a domain name registered.

That was about the hardest part of preparing for the 0.8.1 release, and now that I've done that I should manage to make the changes to the packaging, though I have no doubt that the old name will appear in all sorts of places for a while yet.

Choosing names is an important business, and I should know that from the length of time we spent agonising over names for our children, discarding all sorts of things because they had silly abbreviation collisions (like the "Royal Scottish Country Dance Society" :-) Even then, I think we got the kids names wrong, and the big one should be called "Thumper" with the little one called "Sly", but perhaps that's just a temporary annoyance and in time the names that we registered for them will fit them better.

I also recall Grant once saying that you should never use the word "Simple" in the name of your project, and he should know. DAViCal is no longer particularly simple, although I have attempted to hide the complexity from the user as far as that is possible, and will continue to do so.

Once I get out version 0.8.1 of DAViCal I will finally upload it to Debian, proper. This version has some important enhancements to its DAV spec compliance which are going to be needed by some future versions of Mozilla, and probably other things too, so it's important to push it out as soon as possible now.

Having taken time out to go to the other side of the world to attend DebConf 7 in Edinburgh, and then after spending some time with my family, I have been somewhat distracted from things CalDAV for a wee while now. There are signs that I will be able to put a few more evenings and weekends into it in coming months.

Current Status

With the release of 0.8.0 I believe it is quite a usable application for shared group calendars. We use it at Catalyst for about 80 staff and, while we're not heavy calendar users, it manages without any noticeable performance problems.

There have been an impressive number of downloads from Sourceforge, as well as substantial downloads from my Debian repository, and I believe that the program is in tens, if not hundreds, of installations.

Future Plans

In the immediate future I want to get the basic framework for querying properties about the owner of a calendar or a set of calendars. This will be used by Mozilla soon during their configuration of a new CalDAV source, and I think that Apple iCal probably uses them already. This is partly done, but it's implementation has been slowed by the necessity to refactor the handling of the REPORT method in general to make the code more modular and readable, and to support queries and properties in a more general manner.

The refactoring of the REPORT method handling is in place now, so moving on to the handling of DAV:principal objects should become fairly straightforward. I may end up with a fair bit of quiet, undistracted time over the coming weekend so if I can get in the 'zone', it may get done, and we can start rolling towards a release 0.9.

Release 0.9 will have a new name. One from the cast of thousands that have been submitted to me so far, or one that I will hastily think up in between, but the next released version will not be called RSCDS any longer.

The main goals for further into the future are:

• Maintain interoperability with clients
• Improve specification compliance
• Extend coverage to related specifications
• Documentation improvements
• Configuration improvements
• Installation improvements

Interoperability

I think that RSCDS does fairly well on the interoperability front. Unfortunately I have no access to the preview of OS 10.5, with it's native CalDAV client (though I have been told that it works with RSCDS). Likewise, other commercial CalDAV clients aren't available to me for testing either, so I have concentrated my efforts on supporting the featureset used by the various free CalDAV clients.

My initial work focused around supporting Evolution, in particular, but with the recent effort put in by the Mozilla Calendar team the primary interoperability challenge is to enhance RSCDS to support their areas of development. If I could see how the OS 10.5 client behaves, too, I believe that would help identify a few points to extend, as well as suggesting some future directions.

The best place to review interoperability would probably be at the CalConnect Roundtable 10 but I think that without some sponsorship for airfares I probably won't be able to make that. Maybe next time.

Specifications Compliance

As I read, and reread, the CalDAV (and DAV, and HTTP, and ...) RFCs the compliance with the various specifications improves. Recently I have put a lot of work into the calendar-query report, in particular, which means it now supports querying against arbitrary properties much more comprehensively. This is important because some of the client software is starting to do arbitrary queries also, and it is inevitable that queries for the classification of events, or the percentage completion of todo items will become more common.

And now I notice that there is a new version of DAV in RFC4918, though not too many changes as far as I can see. The intent of this release is mostly to clarify, and slightly to extend, primarily in order to improve client interoperability.

Coverage of Related Specifications

In terms of general calendaring activities, the biggest hole in the CalDAV specification at present is standardisation around the location of other people's schedules. The current draft of the Scheduling Extensions to CalDAV appears to address that, and a lot more besides. I expect to start working on parts of this at some point, but perhaps not sooner than I see a client which starts using it, or when it is ratified, whichever occurs soonest.

Documentation

The documentation is OK. The wiki, in particular, is a reasonable resource for resolving problems (I believe), but it would be good to have some documentation of other things.

One area that could do with enhancement is some documentation of how to check out a copy of the code, and how to provide patches back to me. Even better if other people can maintain their own trees which I could pull patches from, since we're using a distributed version control system (Git) to start with.

Configuration

The administration interface for RSCDS is OK, but could do with a few improvements to make it more usable. Really there are not a lot of reasons to be in the administrative interface, so these improvements should be relatively few, and relatively easy.

This would be a good area for someone interested in helping out to become involved, because it does not entail reading large reams of RFCs, or watching tcpdumps scroll past for the debugging.

Installation

One thing that I have done right, I believe, was to provide the software from the beginning in a packaged form to make the installation easier. Although the software is packaged for Debian, however, it has not yet been uploaded to the archive because I have been waiting for the webapps-common package to enter Debian so I can use that for configuration.

I think I have waited long enough though, so I will upload the next version to Debian for use by a wider audience.

Security

Security has always been a focus for me and I have had the code reviewed for any obvious security flaws. If any particular vulnerabilities are found they will be addressed with appropriate haste.

Retrospective

I've been working on this for a little over a year now, and I think I have largely met my goals for the project. It has certainly been an educational experience for me, and the effect of this work on other projects that I also participate in has also been valuable.

Any new open-source project is always at risk of the developer losing energy and interest, but I believe this one has made it to a state where the bulk of the infrastructure effort has been done, and there are enough interesting challenges in the future to continue to keep me (at least) working on it into the future.

The scope of this project is good, in that it is not at risk of expanding to take over the world. The intention behind this is simply to provide a back-end service for client software which should be very much Someone Else's Problem. In reality there have been times when I have had to get to grips with some of that client software in order to resolve problems, but those have by and large been good experiences.

I see that Jari Urpalainen has written an CalDAV Apache module to support some basic CalDAV functionality.

Excellent.

Meanwhile my own CalDAV server is going through a period of stabilisation before I start in on some of the handling of "Principals", probably next month.

And CalDAV has become RFC 4791 now too.

Here at LCA it seems that some people want shared calendars, so I'm pleaased to be able to tell people that I have spent the last 9 months thinking about and writing a CalDAV server.

While it isn't finished yet (is software ever finished?), it does work just fine with all of the free CalDAV clients that are available, and a number of nice people have translated it into six languages so far.

So if you are at LCA and want to know more catch me at tonight's penguin dinner.