akonadi/docs/history.md

0001 # Historical background # {#history}
0002
0003 # General #
0004
0005 During the last 5 years, after the release of KDE 3.0, the requirements of our users
0006 have constantly increased. While it was sufficient that our PIM solution was able to handle 100 contacts,
0007 300 events and maybe 1000 mails in 2001, nowadays users expect the software to be able to
0008 handle a multiple of that. Over the years, the KDE PIM developers tried to catch up with the new
0009 requirements; however, since KDE 3.x had to stay binary compatible, they were limited in their
0010 efforts.
0011
0012 With the new major release KDE 4.0 it's possible to completely redesign the PIM libraries from
0013 the ground up and use new concepts to face the requirements of 2006 and beyond.
0014
0015 After some discussion at the annual KDE PIM meeting in Osnabrück in January 2006, the PIM developers
0016 came to the conclusion that a service is needed which acts as a local cache on the user's desktop
0017 and provides search facilities. The name Akonadi comes from a divinity from Ghana and was chosen since
0018 all other nice names were already used by other projects on the Internet ;)
0019
0020 # Problems with the implementation of KDE 3.x #
0021
0022 Before digging into the internals of Akonadi, we want to take a look at the implementation of the
0023 old KDE PIM libraries to understand the problems and conceptual shortcomings.
0024
0025 The main PIM libraries libkabc (contacts) and libkcal (events) where designed at a time when the
0026 address book and calendar were files on the local file system, so there was no reason to think
0027 about access time and mode. The libraries accessed the files synchronously and loaded all data of the
0028 file into memory to be able to perform search queries on the data set. It worked well for local files,
0029 but over time plug-ins for loading data from groupware servers were written, so the synchronous access blocked
0030 applications which used libkabc/libkcal, and loading all 2000 contacts from a server is not only
0031 time consuming but also needs a lot of memory to store them locally. The KDE PIM developers tried to
0032 address the first issue by adding an asynchronous API, but it was not well implemented and was difficult to use.
0033 In the end, the design decisions caused the following problems:
0034
0035 * Bad Performance
0036 * High Memory Consumption
0037
0038 Another important but missing thing in the libraries was support for notifications and locking.
0039 The former was partly implemented (at least reflected by the API) but only implemented in the local
0040 file plug-in, so it was in practice unusable. The latter was also partly implemented but never really tested and
0041 lead to deadlocks sometimes, so the following problems appeared as well:
0042
0043 * Missing Notifications
0044 * Missing Locking
0045
0046 The main aim of Akonadi is to solve these issues and make use of the goodies which the new design brings.