GSoC wrap-up - When Persons go into a library (aka PIMO:Person integration)

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!

Comments

[Lacsilva]

Hi! Great work. Is this compilable with kde 4.7.0? Where can one find the code?

[David Edmundson]

Am I reading this properly.
Have you redirected the Akonadi feeders to go straight to nepomuk?
i.e does it go
Akonadi Feeder -> Akonadi-> Magic -> Nepomuk.
or
Akonadi Feeder -> Nepomuk

Is libperson going to have GUI components? It would be cool (from a KDE TP POV) to load a common window for editing people, and have this the same in KMail too.

How does libperson relate/interact with our person classes/model in kde-telepathy (the lib).

Maybe this is a topic for the sprint.

Do you have the Akonadi Facebook feeder? Does it auto-link to our facebook accounts from Tp?

[Marty]

@Lacsilva - Yes and no. It would work with KDE 4.7, but it needs parts from KDE PIM, which were committed only this week.

@David - It goes Akonadi -> Nepomuk Feeder -> Nepomuk, so whatever contacts you'll put into Akonadi will get into Nepomuk.

"Is libperson going to have GUI components?"
Haven't thought of it yet, but now that you mentioned it, it does make sense...although I'll probably keep it away from any GUI and move that to the appropriate GUI tools (the new KAddressBook). I'll try to bring this up on the sprint.

"How does libperson relate/interact with our person classes/model in kde-telepathy (the lib)."
It basically duplicates some of it's work, that's why we decided with George G. to unify these libs. It is definitely topic for the sprint.

"Do you have the Akonadi Facebook feeder? Does it auto-link to our facebook accounts from Tp?"
Yes :)

[D]

Be sure to ping the digikam team when this advanced enough that we can access KDE-wide persons for the face detection

Thanks
Marcel

[Marty]

Hey Marcel!

Definitely will do! It was actually among my initial project ideas - creating Persons from digiKam face tagging ;)

[Kyriakos Brastianos]

Great news and amazing work Martin! Love to see the digikam and facebook integration and looking forward for some more akonadi feeders in the future like linkedin and gist.com or even buddypress. Will any of this goodness be complete or in testing mode with the 4.8 release? Any use of the marble on this? Maybe QZeitgeist?

[Marty]

Hi Kyriakos,

not sure about 4.8 yet. I will know more after next week's Telepathy sprint, where we'll put a shape on that library. Then it won't be so hard to add any extensions to it. As for Marble or QZeitgeist - no plans yet, but might be pretty cool. We shall see ;)

[A Facebook User]

Hey,

though this post is a few month old, I'd like to know about the progress of your project. How is it developing? Can you provide any infos?
Thanks!

[Marty]

@A Facebook User - hi, the development got a bit stalled recently as real life got in the way. We decided to redesign the lib back in September to be more robust and powerful. That library is pretty much ready to be used, but still needing lots of work.

As for apps using it - currently there is none. First will most probably be KDE Telepathy, but even there the use is not clear.

I have lots of task to do in this project, just no time.. :/