Calendar WebDAV

I've been horribly busy and thus haven't found the time to write, now at the Midgard workshop while waiting for sauna I've finally found some time.

I've been working on calendar apart from a week in Rome where we made a specification and some proof of concept code for OpenPSA 2.0

Now after a lot of interesting bugs and tons of testing I finally have "simple" WebDAV support in OpenPSA Calendar, Sunbird (ie Mozilla calendar) sync works two-way, since Apple wants to sell .Mac iCal only supports either subscribe or publish but not two way sync with 3rd party servers.

The vCal import support is not 100% RFC compliant (though none of the clients are either...), durations (neither iCal or sunbird uses them) and repeats are not handled at all, also "floating" times might not go trough timezone guestimation and conversion intact (though that should not be a suprise to anyone) so you should set Sunbird to use UTC as default. I was first hoping I could avoid having to correctly handle vTimezones, but iCal breaks RFC and specifies times in local time in stead of UTC, luckily it includes proper vTimeZone definitions so we can convert the time to server time.

Now users can subscribe to other users' (or calendar resources') vCal feeds as well with their own users, private events are stripped of location etc data and summary replaced with 'Private event' as in web view. I tried returning a vFreebusy in stead but this invariably crashed iCal, however since the vFreebusy export is in the classes it will be easy to publish a wholly public busy list.

GroupDAV support should be quite simple to add now that vCal parsing is solid, however before I can look at that I need to get SyncML working, and after that is done I'll have other projects to work on so GroupDAV will propably have to wait untill after summer unless someone else is up to the task (the hard parts are done in the vcal parser/export methods in the calendar class so it's mainly a case of making the WebDAV service smarter).

The main limitiation currently is that deletes are not handled because there is no efficient way to determine if events exist in database that are not in the iCal dump file, and also for transport issues it's common to only send events from last 6 months and next year or two... SyncML and GroupDAV take this into account and will not have the same problem.