The way an application like Kontact accesses its data shows some common patterns for different data types. For example calendar data and address book data are accessed in a similar way. It can be stored local or remote, it can be stored in text files of different formats or in databases-like systems, there can be different sources of the same kind of data, which need different configuration, data can be read-write or read-only, etc.
To address these problems in a common and consistent way and to avoid duplication of code and effort Kontact makes use of the so-called KResources framework which provides an abstract interface for management of data resources. This framework specifies an API for data resources and the user interface to configure these resources. The resource API includes functions for saving and restoring configuration, for opening and closing of resources, for loading and saving data, for naming resources and for handling write permissions. The framework also provides a management class for handling creation, modification, configuration and persistance of KResources objects and a common configuration module which operates on the abstract API of the resources and so provides a user interface for management of all different resource objects at a central place. Usually there is only one set of resources per data type which represents for example a central calendar or address book for a user shared by different applications or Kontact components.
Deriving from the abstract interface there is a set of classes defining resources for a certain type of data. They are called families in the KResources framework. Currently there are families for example for calendars and address books.
For the different families there are various implementations of concrete resources, e.g. file based calendars using the iCalendar format, address books accessed via LDAP or resources accessing calendar and address book data on a Kolab server. There are also a bit more exotic resources like one that provides entries of a Bugzilla [33] based bug-tracking system as todo list in KOrganizer.
All KResources are implemented as plugins and loaded at run-time, so that memory consumption of Kontact isn't affected by unused resources and dependencies on special external libraries are isolated in the plugins without adding to the dependencies of the Kontact framework application or other components.
The KResources framework also includes a mechanism to notify different instances accessing the same set of resources about changes in the resource configuration. All resource management objects running in the same desktop session communicate with each other for this purpose, either in-process or between different processes by using DCOP. So if a new calendar file is added to the user's calendar in the central resource management configuration module it automatically appears in the calendar view of Kontact, regardless of whether the calendar runs embedded in Kontact or as stand-alone application.