GSoC Weekly report 3-4: The Akonadi-Nepomuk connection

First of all I apologize because last week I was busy doing school stuff and I didn’t get to do much GSoC related stuff. I’m glad to be able to say that today I will assist to my last university class in this academic year and that my holidays (of code :P) period has thus virtual started, because I have also already done my last exam last week, yay.

BTW,  I am going to Akademy too! I already can’t wait to get there 😀

I’ve been investigating how well can I make Akonadi and Nepomuk play together. It seems that my decision of only using Nepomuk through Akonadi is possible. I will thus have an usual Akonadi Resource which provides a set of collections with their items (bookmarks) and subcollections (bookmark folders), and then also I will have some virtual collections.

A virtual collection is a new concept in Akonadi, which still is not enterely developed and Konqueror will probably the second (after Akonadiconsole) application taking advantage of it. A virtual collection has all the properties of a collection, but the items it contains are peculiar. They are not items as in a normal collection, but virtual items, which link to real items inside real collections.

Using virtual collections, besides having your usual bookmarks menu, you will also get in konqueror some virtual collections like: Recently added bookmarks, Most visited bookmarks, Recent tags, or <please suggest your virtual collection in a comment please!>.

You might then wonder… okey so Recently Added Bookmarks would be a virtual collection which contains urls which have been bookmarked recently. But how can an Akonadi virtual collection know which items comply with that? Only Nepomuk knows the relevant information. Here comes the Akonadi-Nepomuk connection:  you can create an Akonadi Virtual Collection with SearchCreatJob class, which takes two arguments: the title of the collection (Unclassified Bookmarks for example) and the SPARQL query string for Nepomuk.

Using SearchCreateJob, I just need to write a SPARQL query that returns only the recently added bookmarks, which is quite trivial. Then Akonadi will handle that query to a Nepomuk persistant query, and it will tell akonadi whenever resources are added or removed to that query. In turn, Akonadi will get the Uri of those added/removed resources, and use that as the remoteId of the Items in the virtual collection, and add/remove those items accordingly. Autotically if there the item with that very same remoteId in a real collection, Akonadi will know, and the item in the virtual collection will have the same properties: same payload, same name, etc.

Usecase to understand and recapitulate:

  1. You click on the star appearing in the location box to bookmark current url.
  2. The url gets added to some Konqueror bookmarks collection (if it’s an unclassified bookmark, it will added to a special-purpose Akonadi bookmark collection called “Unclassified bookmarks”).So now your bookmark has its corresponding real Akonadi item.
  3. Akonadi bookmarks use Nepomuk as storage, so the bookmark is also added in Nepomuk database. In fact it’s only stored persistently there, Akonadi only caches it.
  4. When the new bookmark is added to nepomuk, automatically nepomuk detects that the bookmark enters in the persistant query for “Recently added bookmarks” and adds the new bookmark resource to it, notifying to Akonadi server which was looking for changes in that persistant query.
  5. Akonadi server gets the notification of a new resource added to the “Recently added bookmarks” Nepomuk query,  and adds a new item to its “Recently Added Bookmarks” virtual collection. That new item will actually refer to the item added in step 1, with the same name, payload (a KonqBookmark instance), etc.
  6. Konqueror automagically gets the new bookmark in “Recently added bookmarks” subcollection!

To some people all this might seems like a lot of steps, but to me it sounds like angels. Because all this will make konqueror feel faster and it will make its bookmarking system responsive (non-blocking!) and improve it’s architecture. I am already thinking about how easy will it be to create kross plugins for bookmarks, to be able to support natively new types of bookmarks, to be able to sync with services, and even to easily make all this a bit more flexible and let other apps (Konsole, Kate, etc) use this new Bookmarks System. But, one step at a time :D.

2 Responses to “GSoC Weekly report 3-4: The Akonadi-Nepomuk connection”

  1. 1 LXj mayo 28, 2009 de 5:15 pm

    Why do you make Konqueror to store data in Nepomuk via Akonadi, not directly in Nepomuk?

  2. 2 Eduardo Robles Elvira mayo 28, 2009 de 7:35 pm

    #1 because it’s much more convenient, Akonadi gives me exactly what I need, an abstract layer for accessing and sync data easily as I mentioned in previous posts, it will allow me to do kross scripting, etc. Besides, Nepomuk is optional in KDELibs, Konqueror bookmarks are not, so I cannot depend on it.


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: