Radicale

Technical Choices

Author	Guillaume Ayoub
Date	2010-01-22

The Radicale Project aims to be a light solution, easy to use, easy to install, easy to configure. As a consequence, it requires few software dependencies and is pre-configured to work out-of-the-box.

The Radicale Project runs on most of the UNIX-like platforms (Linux, *BSD, MacOS X) and Windows. It is free and open-source software.

Language

The different parts of the Radicale Project are written in Python. This is a high-level language, fully object-oriented, available for the main operating systems and released with a lot of useful libraries.

Protocols and Formats

The main protocols and formats fully or partially implemented in the Radicale Project are described by RFCs:

HyperText Transfer Protocol (HTTP) RFC 2616
WebDAV Access Control Protocol (ACL) RFC 3744
Calendaring Extensions to WebDAV (CalDAV) RFC 4791
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) RFC 4918
Transport Layer Security (TLS) RFC 5246
iCalendar format (iCal) RFC 5545
vCard Format Specification RFC 6350
vCard Extensions to Web Distributed Authoring and Versioning (CardDAV) RFC 6352

Development Choices

Important global development choices have been decided before writing code. They are very useful to understand why the Radicale Project is different from other CalDAV and CardDAV servers, and why features are included or not in the code.

Oriented to Calendar and Contact User Agents

Calendar and contact servers work with calendar and contact clients, using a defined protocol. CalDAV and CardDAV are good protocols, covering lots of features and use cases, but it is quite hard to implement fully.

Some calendar servers have been created to follow the CalDAV and CardDAV RFCs as much as possible: Davical [1], Cosmo [2] and Darwin Calendar Server [3], for example, are much more respectful of CalDAV and CardDAV and can be used with a large number of clients. They are very good choices if you want to develop and test new CalDAV clients, or if you have a possibly heterogeneous list of user agents.

The Radicale Server does not and will not support the CalDAV and CardDAV standards. It supports the CalDAV and CardDAV implementations of different clients (Lightning, Evolution, Android, iPhone, iCal, and more).

Simple

The Radicale Server is designed to be simple to install, simple to configure, simple to use.

The installation is very easy, particularly with Linux: no dependencies, no superuser rights needed, no configuration required. Launching the main script out-of-the-box, as a normal user, is often the only step to have a simple remote calendar and contact access.

Contrary to other servers that are often complicated, require high privileges or need a strong configuration, the Radicale Server can (sometimes, if not often) be launched in a couple of minutes, if you follow the User Documentation.

Lazy

We, Radicale Project developers, are lazy. That is why we have chosen Python: no more ; or {} [4]. This is also why our server is lazy.

The CalDAV RFC defines what must be done, what can be done and what cannot be done. Many violations of the protocol are totally defined and behaviours are given in such cases.

The Radicale Server assumes that the clients are perfect and that protocol violations do not exist. That is why most of the errors in client requests have undetermined consequences for the lazy server that can reply good answers, bad answers, or even no answer.

As already mentioned, the Radicale server doesn't fully support the CalDAV and CardDAV RFCs. For example, nested filters in queries currently don't work in all cases. Examples of not working queries can be found in issues #120 and #121.

Architectures

General Architecture

Here is a simple overview of the global architecture for reaching a calendar through network:

Part	Layer	Protocol or Format
Server	Calendar/Contact Storage	iCal/vCard
Server	Calendar/Contact Server	CalDAV/CardDAV Server
Transfer	Network	CalDAV/CardDAV (HTTP + TLS)
Client	Calendar/Contact Client	CalDAV/CardDAV Client
Client	GUI	Terminal, GTK, etc.

The Radicale Project is only the server part of this architecture.

Code Architecture

The package offers 8 modules.

__main__: The main module provides a simple function called run. Its main work is to read the configuration from the configuration file and from the options given in the command line; then it creates a server, according to the configuration.
__init__: This is the core part of the module, with the code for the CalDAV server. The server inherits from a HTTP or HTTPS server class, which relies on the default HTTP server class given by Python. The code managing the different HTTP requests according to the CalDAV normalization is written here.
config: This part gives a dict-like access to the server configuration, read from the configuration file. The configuration can be altered when launching the executable with some command line options.
ical: In this module are written the classes to represent collections and items in Radicale. The simple iCalendar and vCard readers and writers are included in this file. The readers and writers are small and stupid: they do not fully understand the iCalendar format and do not know at all what a date is.
xmlutils: The functions defined in this module are mainly called by the CalDAV server class to read the XML part of the request, read or alter the calendars, and create the XML part of the response. The main part of this code relies on ElementTree.
log: The start function provided by this module starts a logging mechanism based on the default Python logging module. Logging options can be stored in a logging configuration file.
acl: This module is a set of Access Control Lists, a set of methods used by Radicale to manage rights to access the calendars. When the CalDAV server is launched, an Access Control List is chosen in the set, according to the configuration. The HTTP requests are then filtered to restrict the access using a list of login/password-based access controls.
storage: This folder is a set of storage modules able to read and write collections. Currently there are three storage modules: filesystem, storing each collection into one flat plain-text file, multifilesystem, storing each entries into separates plain-text files, and database, storing entries in a database. filesystem is stable and battle-tested, others are experimentals.