Subscribe

Meta

In the final part of this mini-series to mark the first Technical Preview release of KDE-Telepathy, I’m going to outline a little bit about the future.

Our immediate plans are further stabilisation. We’ve already received a fair few bug reports and feature requests, and we expect to receive many more. We’ll try to fix as many of these as we can and hopefully put out a 0.2 release in the next couple of months. I’ll leave it to our newly appointed “Release Manager” to announce exactly when this will happen.

Those of you who have been following the blogging and development around KDE Telepathy will probably be wondering what happened to all the Nepomuk integration. Lots of it is already implemented and here at the Desktop Summit I’m adding some final polish and performance improvements to it so that it will be usable soon. Expect the beginnings of this to land in an 0.3 release, at an as-yet-undefined point in the future. This means MetaContacts (or People as we prefer to call them) will not land in the next release but should be present in the one afterwards.

Along with pretty much everyone else, I too am on my way to the Desktop Summit. Currently sitting in the departure lounge at Heathrow, waiting for my flight. If anyone wants to talk Telepathy in KDE, then I’ll be in Berlin all week 🙂

The first preview release for KDE-Telepathy is getting closer. Our release-tracker bug now only has 9 bugs blocking it and many of these already have patches on reviewboard. Our first release will be made separately from the KDE Software Compilation, and should be compatible with installs of 4.6.x or trunk. It will be suitable only for people who like to try out new technologies before they are ready for the mainstream. It will not be feature complete (although we hope many of the basic features will be implemented). It will not be polished (although we do want to know about any bugs or issues you find – that’s why we’re making this release). It will also not be especially deeply integrated with the rest of the KDE S.C. or the Plasma workspaces. There will be a plasma applet for bringing accounts on and offline, but the rest of it is much like a traditional Instant Messaging application.

With expectation management out of the way, let’s take a look at how KDE-Telepathy is going to be in a few releases time. The biggest change from traditional IM clients is that Telepathy is all about Integration. Why should you have a standalone IM client? Real-time Communication and Collaboration features should be available where you want them regardless of the artificial boundaries between applications. Telepathy’s modular architecture of components communicating over DBus enables this to an extent never before possible.

Let’s take a look at the typical uses of Telepathy’s features and how they will work with KDE-Telepathy (not all of what you see below is being implemented presently):

Bringing Accounts on/offline, setting presence and status messages: this will by default be handled by a Plasma applet, although integration with other parts of the workspace could be carried out as appropriate (I’m thinking of that “me menu” concept from Ubuntu as an example).

“Currently Listening To: Foo” in the status message: this would be set by a plugin for the music player being used which updates the Telepathy presence message.

Starting a chat/call: can be done anywhere that knows about people – plasma applets/KAddressBook/Tradtional “Buddy List” app/etc. There is a Summer of Code project to do some work on this stuff in Plasma and another one to make it possible in KAddressBook.

Collaborating on a Text Document: inside Calligra, or any other document editing software.

The key point of all this is that there will be no KDE-Telepathy Application as a single point of interaction for users. In reality, the features of KDE-Telepathy will be integrated with the rest of the KDE experience. The end result – features in more natural and useful places and a more seemless experience for our users.

Once our users stop knowing the name of KDE-Telepathy and start to see it as simply some communication/collaboration features that are always there, that’s when I’ll consider the KDE-Telepathy project to be a success.

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.

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.

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.

Exciting times in Cambridge. Today Collabora moved to a shiny new office, and tomorrow 10 KDE hackers will be descending on that office for a long weekend of hacking/pizza/beer etc.

We’ll be working on the core library of KDE/Telepathy, planning for a first release and hacking on other cool stuff. Since I’m not very good at keeping up with writing here, I’m going to try and give regular updates on identi.ca instead (although I’ll write here too whenever I can manage it).

Release Roadmaps

The KDE/Telepathy project has gained a lot of momentum in the last few months, and many of the basic components we planned to build have started to take shape. As a result, it’s time to start thinking about getting some of that code out there for testing. So, we’re planning to make a preview release some time this autumn. This release will be installable on top of KDE Platform 4.5, and will be suitable for power-users and testers who don’t mind a bit of breakage. We haven’t got a date set yet, but you can track the progress towards this release by looking at the dependency tree of the release bug.

Developer Sprints

In order to get all the separate Telepathy components we’re writing nailed down and working nicely together, and to allow API and Nepomuk usage review, we’ll be having a developer sprint. It will take place from 17th-20th September in Cambridge, UK (venue kindly provided by Collabora). More information about this sprint can be seen on its wiki page.

I’ll be setting off for Akademy at some unearthly hour tomorrow morning, but before I go it’s time for a bit of shameless self-promotion:

On Saturday morning at 10:30 in Room 2, I’ll be giving a talk about Telepathy and KDE. If you want to know what’s going on with Real-time communication and collaboration in KDE, come along – that’s exactly what this talk is about. We’ll be looking at some of the cool stuff that’s already been done, and, even more excitingly, some of the totally crazy new ideas that Telepathy makes possible for us in the future.

If you think Telepathy sounds cool, and want to get hacking on some Collaborative stuff, there’ll be a workshop on Wednesday afternoon in Area 3. There will be Telepathy developers on hand to help you get started on hacking Collaboration or Communication features into you application of choice. No prior knowledge of Telepathy is necessary to take part in the workshop. Since the Akademy schedule doesn’t show the descriptions of the workshops, I’ve pasted the abstract I wrote below:

Telepathy is a cross-desktop framework for real-time communication and collaboration. Built as a series of components centred around DBus, it provides an extensible abstraction layer allowing for easy implementation of communication and collaboration features in applications.

Hosted by the maintainers of Telepathy/KDE and TelepathyQt4, this workshop will help developers understand what can be done with Telepathy and get started using it. The workshop will involve:

Getting development environments up and running with all the necessary bits to develop and test Telepathy/KDE applications.

An introduction to the Telepathy libraries: how they are used and what can be done with them.

Gathering ideas for useful communication and collaboration features that we could implement.

Getting started hacking on some of them.

Participants are invited to take part for all or as much of the afternoon as they can manage. Prior knowledge of Telepathy is not a requirement – there will be several Telepathy developers on hand to help you get started.

I’m finally free from exams and back for another summer of KDE-hacking. While I’ve been gone, Dario has been doing some awesome work on KDE Telepathy integration, and Daniele has got underway with the great “Tubes SoC Project“. It’s great to see all this stuff happening.

Now for my plans for the summer (I hope to achieve at least half of this list before the new term starts in October):

First, Akademy. I’ll be giving a talk and hosting a workshop there. If you are interested in what’s going on with Telepathy or how to take advantage of it in a KDE application, then come along and listen to the talk. The workshop will be ideal for people who want to do stuff with Telepathy but don’t know where to get started.

Presence Plasma Applet and Dataengine. Abner did some great work getting them into shape last year, but the Telepathy framework has gained a few extra relevant features and they have bit-rotted a little, so one of my first aims for the summer is to get them up to release quality.

Account UI – This has been working OK for a year or so now, but it needs some usability/UI design work, and some design changes internally to make it ready for general consumption. Getting this done is aim #2

Telepathy/KDE library preview release. Dario and Daniele are doing some great work on writing KJobs for doing Telepathy tasks. This, along with the widgets from the contactlist and chat UI, will end up in a library for applications to reuse when adding Telepathy features. We need to get this library constructed and make a preview release.

Preview release of all the KDE Telepathy integration. I’d like to get a release out before the end of this summer that will give a preview of KDE-Telepathy. This would be installable on KDE S.C. 4.5 allowing it to be tested and experimented with before it is mature enough to consider inclusion with the KDE S.C.

Improve krfb. A bit different, but still related – I did a lot of work with krfb last summer to add tubes support to it (unfortunately not yet merged). I intend to do a bit more refactoring of krfb code and fix some more of the outstanding bugs, and merge the tubes support ready for KDE S.C. 4.6.