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.