This is a discussion on Calendar Server 7: A Look at Sun's Upcoming CalDAV Release - Solaris Rss ; Hat Tip DougG It might not be widely known at this point, but Sun has been a leader in the CalDAV community , and our investments are about to pay off with the upcoming shipment of Calendar Server 7, included ...
Hat Tip DougG
It might not be widely known at this point, but Sun has been a leader in the CalDAV community, and our investments are about to pay off with the upcoming shipment of Calendar Server 7, included in the Communications Suite 7 release.
Sun is firmly committed to making CalDAV our calendaring protocol of choice. Sun has been very active in the CalConnect community to make sure that our CalDAV service interacts with other vendors and their services. Project Aries has been the name of Sun's CalDAV effort, and for the past year, we've enabled customers to get a taste of our technology through a hosted preview.
Why the need anyways for a CalDAV server?
The challenge in the calendaring space has always been about getting everyone to agree on a standard protocol that enables data to be exchanged between a calendar client and a calendar server, regardless of vendor. To date, we've been using the iCalendar data format for calendar and task data, as specified in RFC 2445. The good news has been that Sun and others have used this common data format. The bad news with this approach has been that, lacking a standard protocol, you end up using one big file to store all your calendar events. Reading calendar info may be fine, but making changes is not. Because your calendar database is essentially one big flat file, the only way a change can be made is for the client to upload a new version of a user's entire calendar data file and overwrite the copy on the server. That's a lot of data to move, for example, when all you have to do is push out a meeting change of one hour. The situation worsens if multiple users want to update a calendar. The last user to overwrite the copy on the server wins and changes other people have made are lost.
Having a real calendar access protocol would solve these problems and provide other nice features, such as calendar sharing, change logs, and free/busy lookups. The first attempt at such a protocol came in 1999 with the creation of the Calendar Access Protocol (CAP). WCAP, or Web Calendar Access Protocol, is an implementation of CAP over HTTP. Sun Java System Calendar Server 6.3 uses this protocol. Unfortunately, timing is everything. When the dot-com bubble burst, work on WCAP fizzled out. The result: Vendors went back to using their proprietary protocols.
Luckily, the situation did not remain the same. Though it took awhile, a new idea emerged to extend the WebDAV protocol to provide calendar specific support. The result was CalDAV and is documented in RFC 4791.
Of course, having an open protocol buys you nothing if vendors do not implement it in popular products. That is a big reason why CAP didn't take off. Fortunately, CalDAV seems to have gained enough momentum to stick around, as envinced by the CalConnect industry consortium, whose charter is to make sure CalDAV implementations work together and are widely adopted.
Yes, calendaring "nirvana" might still be a long way off, but we are getting closer with Calendar Server 7.
For more information on Calendar Server 7, see the following pages:
- Introduction to Calendar Server 7
- Calendar Server 6 and Calendar Server 7 Comparison and Coexistence
- Calendar Server 7 What's NewComplete list of Calendar Server 7 documentation