Akonadi - The PIM Storage Service

Akonadi es un framework de gestión de información personal, desarrollado por el proyecto KDE. Akonadi funciona como un almacén extensible de información para todas las aplicaciones de gestión de información personal. Además Akonadi incluye otros componentes como mecanismos de búsqueda,y una Biblioteca para acceso y notificación de cambios en los datos.

Akonadi se comunica con servidores para enviar y recibir datos, en vez de las aplicaciones a través de una API especializada. La información puede ser recibida de Akonadi mediante un modelo diseñado para recoger información específica (correo, calendario, contactos, etc). La aplicación en sí estará formada de visores y editores que mostrarán información al usuario y le ayudaran a introducirla. Akonadi también soportará metadatos creados por las aplicaciones.

Como Akonadi se encarga de recibir y almacenar datos, lo cual es la parte tradicionalmente difícil del desarrollo de aplicaciones de este ámbito, éste se vuelve mucho más fácil.

Akonadi is a storage service for personal information management (PIM) data and metadata. It is one of the “pillars” (core technologies) behind the KDE SC 4 project, although it is designed to be used in any desktop environment. It is extensible and provides concurrent read, write, and query access.
Akonadi provides unique desktop-wide object identification and retrieval.^[1] It functions as an extensible data storage for all PIM applications. In KDE 3 each PIM application had different data storage and handling methods, which led to several implementations of essentially the same features. Besides data storage, Akonadi has several other components including search, and a library (cache) for easy access and notification of data changes.
Akonadi communicates with servers to fetch and send data instead of applications through a specialized API. Data can then be retrieved from Akonadi by a model designed to collect a specific data (mail, calendar, contacts, etc). The application itself is made of viewers and editors to display data to the user and let them input data. Akonadi also supports metadata created by applications.^[2]
Because Akonadi takes care of data storage and retrieval, which are traditionally the difficult parts of creating a PIM application, development of PIM applications is made much easier. In fact, the Mailody developer Tom Albers demonstrated how a mail reader could be created in only 10 minutes using Akonadi.^[3]

-------------------

Fuente

KDE 4 tiene un entorno de escritorio llamado Plasma. Hay muchos componentes nuevos por debajo:

Soprano, Akonadi, Nepomuk, Strigi

Thomas McGuire, un desarrollador de KDE, ha publicado en su blog personal un completo artículo explicando cada uno de ellos.

Soprano

El primer componente del que vamos a hablar no es propio de KDE, sino que es una biblioteca de Qt.

Soprano es un motor de almacenamiento semántico, es decir, que almacena información en sentencias. Estas sentencias no son ni más ni menos que mapas conceptuales, donde se relacionan conceptos (sujetos y predicados) con acciones (verbos). Podemos ver un ejemplo con la siguiente figura:

En Soprano, este almacenamiento semántico sigue la especificación RDF y para realizar consultas se utiliza el lenguaje SPARQL.

Nepomuk

Esta es una biblioteca propia de KDE que funciona como intermediaria entre las aplicaciones y Soprano. Nepomuk incluye definiciones de lenguaje y métodos específicos orientados a los posibles usos que puedan darle las aplicaciones de KDE a Soprano.

Estas definiciones de lenguaje (ontologías) sirven para normalizar el almacenamiento. Sin una ontología definida, una aplicación podría almacenar «Mónica vive en Sevilla» y otra que «Mónica reside en Sevilla» y los datos de una aplicación no servirían para la otra. Respetando la ontología se consigue una información mucho más útil.

Ahora veremos qué clase de datos se almacenan, porque eso es lo que hacen exactamente Strigi y Akonadi, almacenar.

Strigi

Strigi es el componente encargado de recoger información del sistema de archivos, extrayendo toda la información relevante para almacenarla, pasándosela a Nepomuk.

El problema con este componente es que mirar en los archivos, extraerles la información y almacenarla consume una cantidad enorme de recursos. Tampoco está tan claro qué información es relevante y cuál no, ya que en un determinado momento podría llegarnos a interesar buscar todas las imágenes de menos de 300px de ancho en las que predomine el color azul, pero es poco probable.

Akonadi

Además de ser el culpable de que KDE dependa de MySQL, este componente es el encargado de obtener información referente a contactos, correos y calendarios (y todo lo que entre dentro del concepto de PIM) de todo tipo de fuentes externas y de proveer un acceso unificado a todos esos datos a las aplicaciones.

Lógicamente, Akonadi necesita almacenar en algún sitio todos los datos que maneja, ya que se obtienen de fuentes muy heterogéneas. Es por eso que utiliza una base de datos relacional y depende de MySQL (aunque en un futuro soportará otras soluciones como SQLite).

Los datos que son relevantes para las aplicaciones se pasan a Nepomuk para poder realizar búsquedas aprovechando las ventajas que ofrecen las bases de datos semánticas

Source

Mission Statement We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval.
Features

• Common PIM data cache
  • Type agnostic design
  • Extensible
  • Generic offline access, change recording and replay
  • Generic conflict detection and resolution
  • Resources are groupable by profile
  • Items composed of independently retrievable multiple parts
  • Zero-copy retrieval possible
• Concurrent access allows background activity independent of UI client
  • Syncing mail, calendar, addressbooks to remote servers
  • Syncing with mobile devices
  • Permits semantic desktop infrastructure to access PIM data
  • Archiving
  • Indexing
  • Out-of-process search
• Multi-process design
  • Crash isolation
  • Large items can't block whole system
  • Linkage by IPC allows proprietary components
  • Thin client installations can share components for scalability

Architecture

This diagram illustrates the basic aspects of the Akonadi architecture. It's built around a central storage which is accessed through a language and platform neutral protocol. On top of this protocol a set of APIs is provided which are used to access the PIM data in the storage. There are two kinds of users of the APIs. First, there are the applications like Kontact, KOffice or Evolution. Second, there are resources which transfer data between the central Akonadi storage and external sources. This can be groupware servers like OX or GroupWise, other storage mechanisms like iCalendar files or access through standard protocols like POP or IMAP.

The diagram only lists some example applications and resources. Akonadi is designed to be accessible to a broad range of applications and resource implementations. It's part of the concept that it's easy to add additional APIs and users of the APIs.

Code

Akonadi is currently being developed in the KDE Git and Subversion repositories. You find the Akonadi server at kdesupport/akonadi (Git) and the KDE Akonadi client libraries at trunk/KDE/kdepimlibs/akonadi (still SVN).

Releases of the server can be downloaded here, the client libraries are included in the regular KDE releases beginning with KDE 4.1.