The Vision of KDE-Telepathy: Part 3 – The Implementation

This article is the final part in a series of 3 articles (Part 1, Part 2) covering the vision and high-level design decisions of the KDE-Telepathy project. It is highly recommended that you read Part 1 and Part 2 of this series before this part, as it won’t make as much sense without them.

Now that Nepomuk has been identified as the solution to our problem, we should address how to implement KDE-Telepathy with that in mind. The diagram below shows very roughly the architecture of our system.

The Telepathy Framework interfaces with Nepomuk, and the user facing applications interface with Nepomuk. This allows Telepathy data, such as presence and message history, to be consumed by applications which know nothing about Telepathy, simply by retrieving the data from Nepomuk. There are two areas in which infrastructure must be developed: between Telepathy and Nepomuk (Service Side) and between Nepomuk and the User Facing Applications (Client Side).

Service Side Infrastructure

The main component on the service-side (between upstream Telepathy and Nepomuk) is the Telepathy Nepomuk Service. This is a daemon running in the background that is responsible for keeping all the basic Telepathy data synchronised into Nepomuk (including your own presence status, and your server-side buddy lists and their presence statuses etc). This service ensures that Nepomuk always holds up to date and accurate data from Telepathy.

Client Side Infrastructure

On the client side, although applications can access the Telepathy data directly from Nepomuk, a library, telepathy-kde (still in the early stages of development) exists whose purpose is to abstract away much of the complexity of writing applications that are Telepathy aware. Its purpose is to provide easy to use classes, models and UI widgets for contact lists, starting and handling channels, text/voice/video chat UI components and everything else commonly needed for adding Communication and Collaboration features to KDE applications, correctly integrated with Nepomuk.

Of course, there are many other components to the Telepathy-KDE project, Telepathy being a DBus centric framework leads to a large number of separate components (a topic for another blog post some day), but only those components directly related to the use of Nepomuk have been presented here.

The Vision of KDE-Telepathy: Part 2 – The Solution

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.

The Vision of KDE-Telepathy: Part 1 – The Problem

This article is Part 1 in a series of 3 articles covering the vision and high-level design decisions of the KDE-Telepathy project. Recently we have gained a large number of new developers in the project, which is absolutely fantastic, but this has made one major weakness of our project become apparent. It has existed for over 3 years now, but we don’t have any written record of why we are doing things the way we are. This series of blog posts is an attempt to rectify that.

Background: Interacting with People

When using a computer, we often need to interact with one another. We do this in many different ways. Let’s take a list of just a few fairly diverse examples:

• Chatting with my friends
• Video Conference with my Team at work
• Emailing my family from time to time
• Looking at the hilarious photos of cats that my friend keeps sending me
• Working on a project description document with my work colleagues
• Looking at my friends’ holiday photos

As you can see from that list, there are a huge range of different contexts in which we interact with other people. Sometimes we want to communicate with them, as illustrated by the email, video conference and chat examples. Sometimes we are looking at stuff that came from them, such as the lolcat pictures. Sometimes we are working together on something, such as the project description, and sometimes we have something that is connected to them, such as the holiday photos they are in. The one thing that all of this has in common is that there is information to do with people.

Despite this information coming from a range of different sources, to me, as a human being and a computer user, it is all fundamentally the of the same type, so I would expect the information to all be accessible in the same place. Photo tagging, chat history, collaborated documents, files I got sent – they could all be related to the same person, so my computer should treat them as such. Think of the Facebook friend feed – all the information about a person, whatever its source and whatever its purpose, is presented in a single unified place. The reason: because it’s all about the same person. The rest is just implementation detail, and as all programmers know, user experience should never be dictated by implementation detail.

The Problem: Disparate Technologies

Now that we have developed this fundamental vision, lets take a look at the problems we are going to face living up to the statement at the end of the previous section – namely not compromising the vision because of implementation difficulties.

The problem is this: while all the information about people described above seems fundamentally the same from the user’s perspective, in the KDE Software Compilation, different aspects are handled by completely separate applications or frameworks. Email could be handled by KMail, Real-time communication can be handled by Telepathy, Photo tagging can be handled by Digikam and so on.

What can we do? There are several different ways of approaching this problem. One tempting solution that may present itself to the armchair API designer might be to build an API to unify all this information about people. But then that would require KMail and Digikam to be rewritten to make use of this new API. A massive, not to mention entirely impractical and undesirable task. Perhaps instead we should create some interfaces for the applications to share information with each other? This sounds OK to begin with, but then imagine we used Mailody, Gwenview and Kopete instead – they would need to support these interfaces too (as would every other application we could replace these with). And what if there was a desire to make some other related set of data link together across applications? Then we’d need another set of interfaces and we’d have to modify all the applications all over again. Another unsustainable proposition.

What we really need is a central store for this kind of information. It should be supported by all KDE applications, but it should not be necessary for applications to support each other’s underlying libraries and frameworks to make use of the data. It should be capable of storing not just information related to people, as concerns us here, but also information related to anything else, so that there is no need to create another new solution should other genres of application decide that valuable information can be shared between each other.

Tune in again tomorrow for Part 2 in this series to find out the solution to our problem.