On Sunday 21 August 2011 09:36:02 Dietz Pröpper wrote:
> if I got that right, current (4.7) kdepim uses akonadi as a storage backend
> for everything.
Hi, that's the most common misunderstanding about the new KDEPIM structure: Akonadi is not the storage backend, it is a unifying cache for several storage backends with which applications can interact.
Afaik the vCalendar file storage backend and Maildir file structure backend are both supported by Akonadi resources as shipped with the current (current as in shipped with KDE SC 4.7, but not yet provided by Debian) KDEPIM releases. This allows easy adding of new resources for various backends like, e.g., a Facebook resource. , Yahoo calendar , Google calendar, eGroupware.
Hence, this does not mean that the "old" storage resources will all vanish. For instance, I currently (running a self compiled KDEPIM 4.7) use an IMAP mail server, a vCalendar file, an addressbook as vCard directory, an eGroupware server for addressbook and calendar (by the Akonadi GroupDAV resource), and a Google calendar (by the Akonadi CalDAV resource).
The indexing and semantic desktop stuff then is a different topic: those things are done by the Nepomuk framework, feeding a big Virtuoso datasbase. For performance reasons it is possible to switch indexing of mails off (well, then tagging and full-text search in mails is also switched off).
Coming back to your questions: The reason why the currently with Debian shipped KMail application relies on Akonadi is afaik the connection to KAdressbook, which already switched its storage system to be cached by the Akonadi server with its 4.6 release. With the 4.7 release this switch is also done for most of the remaining PIM applications (at least with KMail and KOrganizer). But as with this switch all storage access functionality moved from the KDEPIM applications to Akonadi, using KDEPIM without Akonadi is not possible.