Thanks to the wonderful folks at Linagora, I was able to spend the last three days at the Calconnect XXXI meeting in Bedford, England. The goal of this meeting is to get server and client vendors together in a room both for ad-hoc testing and discussions on calendaring standards.
Before arriving, I’ve set myself the goal to go through a big list of bugs that have been sitting around in our CalDAV component to see if they can be resolved. It turns out that I was able to close 48 of the 76 bugs I had picked out:
A good amount of the bugs I’ve resolved were sitting and waiting for any one of our contributors to reproduce with a specific server. This is often a problem because the time it takes to set up and configure the servers is time consuming. The great thing about being here at Calconnect is having a testing instance most of the reported servers readily set up. Not only that, but engineers from the respective servers are sitting together at a table and can answer any questions that may arise, or comment on potential bugs that have been fixed in later versions.
The other category of bugs are support issues, duplicates and bugs that haven’t received an answer from the reporter. These could have been found outside of Calconnect, but its still a good opportunity to take the time to handle these.
Eight of the remaining bugs already have a patch attached, four of them were created while I was here. There is also a new feature coming up that makes it easy to share calendars with other users directly from Lightning. This requires the server to support caldav-sharing, for example the Apple Calendar and Contacts Server and fruux.com.
In the next few days we will be going on to the standards discussions. I am actively involved as the chair to TC-API, a technical committee dedicated to producing an abstract calendaring model that ensures that vendors integrating calendaring into their products are aware of the implications of calendaring and scheduling, hopefully resulting in better interoperability in the future. Another goal we have is to find a common understanding for a REST API that is geared towards webpages, which may become a standards document some day.