The Vision of KDE-Telepathy: Part 2 – The Solution
Posted by grundleborg on April 2, 2011
This article is Part 2 in a series of 3 articles (Part 1) covering the vision and high-level design decisions of the KDE-Telepathy project. It is highly recommended that you read Part 1 of this series before this part, as it won’t make as much sense without it.
The answer, of course, is Nepomuk. It’s a generic storage place for information, it doesn’t require an application to speak the Telepathy and KMail APIs in order to get data about people, and its already a part of the KDE Platform, meaning it has widespread adoption in KDE applications. Perfect. And the best bit is it already exists. There are few things more satisfying than finding a massive, fundamental problem you face has already been solved.
However, Nepomuk can only truly work if everyone uses it. The more that KDE applications make use of Nepomuk, the more the benefits of that usage increase for our users. KDE-Telepathy alone making use of Nepomuk is a start, but we need to see those other applications that were mentioned in Part 1 making use of it too. That way, all the information related to people will be centrally accessible by any application, making the sort of unified approach to information outlined in our vision become possible.
The Hard Dependency
There are inevitably some people who will now ask “What about users without Nepomuk?”. KDE-Telepathy has a hard dependency on Nepomuk. We are trying to build a better user experience for the future, not just reimplement the same old Instant Messaging applications of the past (I have nothing against the applications like Kopete and Pidgin, it’s just that I believe we have a chance to make something new and considerably better). As I hope you will have gathered from Part 1 and this blog so far, the purpose of this project is to create a unified experience, and for that, we need a framework like Nepomuk. Making Nepomuk optional would mean making the entire goal of the project optional, which is a completely pointless move. Making some other fallback technology to replace Nepomuk when it is not present is equally fruitless, as I hope I made clear in the penultimate paragraph of Part 1.
To those who say that Nepomuk is slow/bloated/$negative_adjective_of_choice, I say this: it has improved massively since it was first introduced, and our experience has shown that making use of Nepomuk is the best way by far to make it improve further. The areas of Nepomuk used by KDE-Telepathy have improved dramatically due to our feedback and involvement with Nepomuk developers. So, if you feel like complaining about Nepomuk, instead, put your time to better use and file some bug reports. We did. That way, the problem might actually get fixed.
Tomorrow brings the final part in this three-part series on KDE-Telepathy, in which a high-level overview of the design of KDE-Telepathy with regard to Nepomuk is presented.