Muchos sabemos de KDE 4 que tiene un entorno de escritorio llamado Plasma. Somos conscientes de que hay muchos componentes nuevos por debajo, pero no sabemos exactamente lo que son. Soprano, Akonadi, Nepomuk, Strigi... ¿Qué hace cada uno y cómo interactúan entre ellos?
Thomas McGuire, un desarrollador de KDE, ha publicado en su blog personal un completo artículo explicando cada uno de ellos, así que vamos a aprovechar para hacer nosotros también un acercamiento.
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
En resumen
Este diagrama intenta sintetizar los componentes de los que hemos hablado y las relaciones existentes entre ellos. Visto así, no parece tan complicado, ¿verdad?
Espero que este acercamiento os haya disipado más dudas de las que os ha generado, pero seguro que todavía hay algo que no está del todo claro. Si queréis añadir algo, profundizar más en algún componente o hacer correcciones, tenéis abiertos los comentarios, como siempre.