KDE PIM Sprint Report: Day -2


The KDE PIM sprint in Brno, Czech republic starts this Friday, but some KDE developers just could not wait and decided to come to Brno already on Monday to work with the Red Hat KDE Team. Some of the stuff we are hacking right now is PIM related, but we also want to use this few days to work on other projects that we are involved in, but that are not strictly related to KDE PIM.

So I’m just sitting right now in the office with Àlex Fiestas, David Edmundson, Vishesh Handa, Martin Klapetek and my colleagues Jan Grulich and Lukáš Tinkl. I’m waiting for Àlex to finish polishing his port of BlueDevil to BlueZ5, so that we can start hacking on KScreen – there are far too many bugs that need our attention and we’ve been neglecting KScreen quite a lot in the past few months. We want to fix the annoying crash in our KDED module, solve a regression that my bold attempt to fix an another crash in KDED caused and discuss the future direction of KScreen – me and Àlex have different opinions on where we should go next with KScreen so this is a great opportunity to find a common path :-)

Vishesh has been relentlessly working  on improving the semantic technologies in KDE and from what I’ve seen, it’s something to really look forward to ;-)

Yesterday, me and Vishesh discussed the possibility of using Akonadi for handling tags of PIM data (emails, contacts, events, …) and I implemented the feature into Akonadi and the Akonadi client libraries – only as a proof of concept though, I have no intention of shipping it at this point – much more work and discussion is needed about this. I also made further progress with implementing the IDLE extension to the Akonadi protocol. It allows the Akonadi server to send notifications about changes to clients using the Akonadi protocol, instead of D-Bus (performance++)

KDE hackers fighting bugs and bringing the awesome to our users

KDE hackers fighting bugs and bringing the awesome to our users

David Edmundson and Martin Klapetek have been working on creating Plasma theme for SDDM (a new display manager that for example Fedora intends to ship instead of KDM), and today they’ve been improving KPeople, the meta-contact library used by KDE Telepathy and that they will also integrate with KDE PIM.

My colleagues Lukáš Tinkl and Jan Grulich are working on plasma-nm, the new Plasma applet for network management in KDE.

More people will arrive to Brno tomorrow and the rest of KDE PIM sprint attendees will arrive during Friday, when the real sprint begins. Stay tuned for more news (not just) from the PIM world ;-)

6 thoughts on “KDE PIM Sprint Report: Day -2

  1. Karellen

    “Yesterday, me and Vishesh discussed the possibility of using Akonadi for handling tags of PIM data”

    Wait, what? I thought one of the main reasons for Akonadi was that it provided a generic way to store all PIM metadata. I mean, Akonadi is built on top of NEPOMUK, which is built specifically to store metadata – metadata LIKE TAGS!!!

    How is KDE PIM not using Akonadi to store tags already? Where are the tags currently stored, if not there?

    Heck, from the 2009 article Akonadi, Nepomuk and Strigi explained, we learn that “We use Akonadi agents to feed information about contacts, events and mails into Nepomuk. […] for example we have a working tag resource to show all your mails tagged with specific tags”

    So, if KDE PIM isn’t using Akonadi to store the tags in Nepomuk, what the heck is going on?

    • Akonadi does not STORE anything, it’s a cache. Not for meta-data, but for the actual data. Meta-data are stored in Nepomuk. Akonadi does not build on top of Nepomuk in any way, but they stand side by side. There’s the Akonadi Nepomuk Feeder which processes data cached in Akonadi and stores the indexed metadata in Nepomuk. Then as you pointed out there’s the Akonadi Tag Resource which queries Nepomuk to get list of tags and relations between entities referring to a Akonadi items (emails, contacts, ..) and tags and exposes them to Akonadi, so that you can see them in KMail etc.

      So tags and relations between tags and records referring to a Akonadi entities are stored in Nepomuk, not in Akonadi.

      The concept we discussed was to store tags of the entities in their remote storages (like on IMAP server, in iCal or vCard files, etc.) and cache the tags and the entity-tag relations in Akonadi (again, we can’t store anything in Akonadi, it’s a cache).

      If we ever decide to go this way, I’ll write a full blog post about it. For now it’s just a concept with many problems to be sorted out first.

  2. Karellen

    “Akonadi does not STORE anything”

    Sorry, my terminology was bad. In my comment s/store/handle/g

    “it’s a cache”

    This is kind of off-topic, but that’s not how I think of it. (This could be my problem though.) I think of Akonadi as a unified API, configuration, and data access layer for PIM data. Yes, the implementation does cache the data it provides access to, but as far as I can tell it doesn’t strictly have to. It could still do the main part of its job without the cache, albeit with large delays and latencies. Is that horribly wrong?

    “Akonadi does not build on top of Nepomuk in any way”

    Oh, I thought Nepomuk was a strict dependency of Akonadi. I didn’t realise it was possible to build/configure Akonadi without Nepomuk. My mistake. Thanks.

    “The concept we discussed was to store tags of the entities in their remote storages”

    Ah, so the tags are currently being stored directly in Nepomuk, not going through Akonadi, and are kind-of separate from the “inline” Akonadi-derived metadata (from, to, subject, etc…); the change would be to store the tags via Akonadi in the back-end, where they would then be equivalent to the rest of the “inline” metadata.

    • Yeah, Akonadi is an abstraction over various PIM end-storages accessible through unified API. What I was describing was more the Akonadi server (sorry, I’m now digging in the server, so I’m in a “different mode” of seeing Akonadi :D ). You can indeed disable the cache part and have a “direct” access to the end-storages through a single API.

  3. Do you still use Arch Linux or if you have completely converted to Fedora? Do Red Hat guys tends to use Fedora over other distributions? I am wondering why did you move away from Arch to Fedora, how was the transition (no AUR) and how do you get by with software updating every six months?

    I wanted to give Fedora a serious try and it seems Gnome is the focus of Fedora/Red Hat. Does KDE ever feels left out of the game or a second class citizen in Red Hat universe?

    On the topic of KDE PIM. I have recently started using KMail. KMail worked fine until a few versions back of KDE but currently KMail has become so slow that it is impossible to use it. Each mail takes 1-2 minutes to show up, even the old read mail takes that long to show the text. Akonadi Console tells me that KMail is constantly syncing folders which makes it excruciatingly slow. I did file a bug but it didn’t get any attention so far. I had to eventually let go of KMail and go back to web app.


    • I switched to Fedora because it’s easier for me to reproduce bugs and maintain Fedora packages there. Most people use it, but it’s not enforced (there are people here using Gentoo for instance). I miss AUR a lot, but Fedora has many packages in it’s main repositories.

      GNOME is the first-class citizen in Fedora, and KDE is staying a bit behind, but we are doing our best to ensure the best experience for our KDE users too – for me KDE on Fedora works just perfectly.

      Wrt KDE PIM, I’ll comment on the bug.

Comments are closed.