So the GSoC 2011 has ended and it's time to look at the project state and it's future. My project was to integrate Nepomuk's PIMO:Person into PIM and eventually add some IM features into PIM applications. So let's see where we're at.
The cornerstone of KDE PIM, Akonadi, currently feeds all contacts into Nepomuk in form of NCO:PersonContact. So the first logical step was to create a service that takes these PersonContacts and creates a Person from them. For this to work properly the Akonadi feeders needed a port to the new Nepomuk Data Management Service. We pulled this through together with Christian Mollekopf, who ported the feeder base and some of the feeders too. The contact feeder was then ported by me after quick introduction of teh DMS by Sebastian Trueg and with whole lots of help from Vishesh Handa, to whom I really owe a great deal of thanks for his answering to my constant bugging about Nepomuk behaving in weird ways. Thanks guys for helping out.
After the contact feeder was using the DMS, I could make use of Nepomuk Resource Watcher awesomeness to watch for new contacts and create/find a Person for them. This service is done and has a basic functionality, ie. if it finds an already existing Person for the new contact, it adds it to that Person, otherwise it creates new Person with this contact. This process can sure use some improvements and use of heuristics, these are on TODO.
Once we had some Persons in Nepomuk, we could start making use of them. Since PIMO:Persons are planned to be used on several places throughout the system, a shared library for working with Persons came into mind. So libperson was born. This library currently features a model for accessing the Persons' data and also methods for storing Persons in Nepomuk.
Coming from KDE-Telepathy land where we're in the process of transition to Nepomuk-based contact list, I started looking on how to make use of Telepathy (IM) data in libperson. Our Telepathy feeder was pretty much very usable, it just needed few slight modifications in the storing procedures. Well in fact the storing procedure needed (and still needs) a port to Nepomuk's DMS, but as George Goldberg had it planned for some time, I did only those slight modifications that enabled to effectively use IM data in libperson.
But soon I discovered that the library is not good in terms of performance and design. After some longer discussions at Berlin Desktop Summit with my mentor Volker Krause, the Telepathy-Nepomuk developer George Goldberg and few others, we've realized that libperson is somewhat duplicate of what we have in KDE-Telepathy and that we could probably unify our efforts.
After BDS I quickly rewrote the library to be only a small layer sitting directly above Nepomuk and to use raw Nepomuk data as much as possible, converting them to easy to use data "on the fly" through convenience API of the library. After a short discussion with Sebastian Trueg and George Goldberg we decided to make it even a thinner layer on top of Nepomuk, basically to serve as a (somewhat hybrid) proxy model with dynamic queries in the back with specific PIM and IM extensions. As there is a Telepathy sprint coming in two weeks we left the library design decisions and coding itself for then.
As for the rest of my GSoC, I created two tools which take advantage of libperson. One was for manual creation/merging of Persons. It's working ok but could use some more love. The second tool is for viewing persons and it's aimed as a new generation KAddressBook with Persons/libperson in the back.
Currently the Nepomuk Person service and those two tools are frozen as I want to sort out the library first. My personal goal for libperson is to be a life easing tool while working with PIMO:Person. Once the rewrite of the library is done, I'll rewrite the service so it can take full advantage of libperson. I hope this to be done by the end of September, then we'll spend some time on perfecting the lib and after that the KAddressBook 2.0 (as I'd like to call it) should get some attention. So that's the plan in short.
As for the GSoC itself - it has been a wonderful experience. I learnt a lot about writing libraries (my first lib ever), about using d-pointers, about API and all that. I also got to walk the darker corners of memory and cpu usage optimization, shared pointers and learnt why using a QObject for everything is not always good. For most of these things I owe a big thanks to Volker Krause, my mentor, who provided me with insightful advices, notes and comments. And of course by passing me in the finals:) And by this I'd like to give a big shout out to the whole KDE community (program admins included!), which makes working on KDE a real good time. Thank you all!
And lastly, thank you Google for this opportunity!