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.