Developing a CalDav server

Question

I have a set of events saved in my database (a very special database, so I can't use some popular open-source servers with, say, MySQL). Now I want to build a CalDav server (by Java) so that a user can connect his calendar client to it to retrieve or modify events. I'm new to this so have a lot of questions, hope you guys help me out.

1. What are the general steps?

2. Do I need to offer a servlet? If yes, then what must I return for a request? a JSON or XML or .ics file?

3. When a user subscribe to my calendar, does that mean that his client will pull my server (call the servlet) after an interval.

Update: this is 1-year old question since I first asked but I got quite some upvotes, so I'm obliged to provide some info: I ended up using Milton library http://milton.io/, it abstracts away the servlets, you just have to write functions to return data. The author of the library is quite helpful and informative. The end-result: our caldav server has worked.

I also accept Evert's answer.

Answer 1

Let me give it a try ;-)

What are the general steps?

As mentioned by Evert you need to implement a CalDAV server. Depending on what features you want to support, this is non-trivial and requires understanding of the relevant specs (iCalendar RFC 5545 and CalDAV 4791, WebDAV RFC 4918).

What are the general steps to implement a CalDAV server? You need HTTP entry-points to:

a) serve the account information (called principals in WebDAV), this includes under which URL the calendars of an account live

b) serve the list of calendars (called the calendar home, the principal info from a) points to this)

c) serve the actual calendars, that is, the events contained within those. CalDAV calendars are special WebDAV collections of 'iCalendar' resources. iCalendar is the format in which the events are represented.

Depending on what CalDAV features you want to support, this can be way more complex (e.g. server side scheduling). There are optimizations for faster syncs (sync-reports), or uploads, etc. You don't need all of it to get started.

Do I need to offer a servlet? If yes, then what must I return for a request? a JSON or XML or .ics file?

As Evert says, how you implement the HTTP endpoints is your choice. Servlet's are one viable option. Principal information, calendar lists and URLs to items within a calendar are returned in (WebDAV) XML (multistatus responses). The actual content of an event needs to be returned in the iCalendar (.ics) format.

When a user subscribe to my calendar, does that mean that his client will pull my server (call the servlet) after an interval.

Yes.

Some CalDAV implementations also support Push (where the server can tell the client when new data is available), but that's not yet standardized and implementations vary a lot. The polling can be kept fast if your server implements CTags and sync-reports (RFC 6578).

Answer 2

Read the RFC: https://www.rfc-editor.org/rfc/rfc4791

Not just once, you want to at least read it top to bottom 4 times.

More than that, you should probably also read the RFC's for WebDAV, WebDAV ACL and iCalendar.

Any answer you would get here would be a repetition of what's in there, and attempting to simplify this is rather futile, because you really need a full understanding of most of the specification.

To answer your questions specifically:

1. Is entirely too vague to answer. The general steps would entail understanding the specification, and writing the server. Specifics are encouraged.
2. You need something that can respond to HTTP requests. Whether that's a servlet or something else is less important. CalDAV is an extension to HTTP. XML reports are returned for meta-information, and iCalendar is the default format for the actual calendar data. For many http requests iCalendar is wrapped in xml bodies. These days servers are also starting to support xCal and jCal. The latter two are optional, you must have iCalendar support.
3. Usually, they will poll at a client-defined interval. There are pub-sub mechanisms, but currently there is no standard for them, and there's various implementations out there. Discussions have started to come up with a standard transport for this, but this may take some time to complete. (years)