open source stuff

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.

27 Responses to “The Vision of KDE-Telepathy: Part 2 – The Solution”

  1. Mario Fux said

    Morning George

    Thx for your articles about Telepathy (and Nepomuk). They are very interesting to read. I like it very much that you use Nepomuk as such a fundamental dependency and that you as well see the potential of Nepomuk.

    And thus sorry to hijack your blog but I’d like to inform the readers of this nice articles that the Nepomuk team is going to have a meeting in June in Randa [1] and we could still need some new blood and interested application developer who’d like to integrate their applications with Nepomuk technology.

    As the registration for this meeting [2] is going to close this weekend I’d like you to contact directly me if you want to participate as well: fux At kde PERIOD org.


  2. KenP said

    Is it possible to have a plugin for SIPE for KDE-Telepathy? It allows one to connect to MS Office Communicator which, at my workplace, is the internal messenger service. Currently, pidgin is the only one to have a plugin for it — via pidgin-sipe.

    • grundleborg said

      Pidgin gets its SIPE support through libpurple, which is the same library as used by the telepathy-haze connection manager. This means that just install KDE-Telepathy and telepathy-haze, and SIPE will automatically be supported by KDE-Telepathy.

  3. rrh said

    Hello George!

    Glad to hear about progress in KDE-Telepathy (and the fresh blood). What I am interested in is, if KDE Telepathy will provide Skype via Skype Kit? I can’t see Skype being supported by ‘native’ Telepathy but it is in Nokia n900/Maemo. I reckon that it would be the power feature that many users would love.
    What’s your opinion?

    • grundleborg said

      Thanks 🙂

      As for Skype, I know and love the Skype CM on the N900, but I don’t know much about Skype possibilities on the desktop, and am not familiar with Skype Kit myself. However, if Skype Kit provides the needed API to build an open source Connection Manager for Telepathy, then it’s pretty much problem solved already :).

  4. kboite said

    I’m a truly believer in a decentralized Internet/p2p architectures (i’m still amazed by this blogpost on the planet : Enabling easy sharing with deep semantic technologies integration (nepomuk ftw) is the way to go and telepathy seems perfect for instant messaging/collaboration capabilities (even for fileshaing it is a good first step before the p2p integration reaches a mature integration with the desktop).

    In your first part, in your computer use cases description, you forgot to mention all the social networking stuff people uses everyday : it contains not only instant messaging but also half-persistant (status updates) and persistant (profile) datas. Would be more than great if we had a telepathy-twitter/telepathy-onesocialweb, etc.

    • grundleborg said

      You are right, I did forget to mention social networking. However, I don’t believe telepathy is the right place for this. Telepathy is about real-time stuff, which social networking is not. It should be taken care of somewhere else (perhaps KDE PIM?). But, as long as where it is taken care of is Nepomuk integrated, that won’t matter for the user, because the data will all be integrated together by our good friend Nepomuk.

      • kboite said

        “Telepathy is about real-time stuff, which social networking is not.”
        I disagree : while social networking is not only about real time, real time communication is a huge part of social networking.
        Twitter is not an instant messaging system, but it’s all about real time (and integrating tweets in search engines is strategic for adding real time value to them).
        Google Wave was the ultimate mix between real time and non real time stuff (and was supposed to be yet another social network).
        Finally, OneSocialWeb/Jabber extensions also mix real time and non real time stuff.

        But maybe all of this is achievable with a deep kde-telepathy’s integration in akonadi.

      • grundleborg said

        Well, the stuff that is instant-messaging belongs in telepathy, the rest belongs in Akonadi. And with good integration with Nepomuk, KDE application developers don’t need to be too worried about which data comes from which framework – they can focus on building applications that mesh the different data as much as they want.

  5. Sławek said

    As I remember, Akanodi supports multiple data engines and Nepomuk too.

  6. […] in again tomorrow for Part 2 in this series to find out the solution to our […]

  7. […] 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 […]

  8. damian said

    This seems great plans, but what about akonadi?, isn’t it designed for purposes like this one? Also, it uses nepomuk.
    And about nepomuk performance/resource consumption, it’s still not possible to run nepomuk satisfactorily on a netbook.
    Still there are a few things that should be fixed before it’s really mainstream, like database not shrinking when data is removed, or when to start refreshing the database (in the case of strigi).
    These problems are related to virtuoso or to nepomuk? I’d like to help in one of them.

    • grundleborg said

      Akonadi is a caching system for PIM data. In the diagram above, it would go in the same level as Telepathy. Data from akonadi is also fed into Nepomuk, and the connections between PIM data (from Akonadi) IM data (from Telepathy) and any other data are all made in Nepomuk.

      The performance of Nepomuk is improving rapidly, although I agree that it still has some way to go. I would note that we are talking about just Nepomuk here – not the strigi indexing, which is generally the problem people have with Nepomuk.

      If you want to help out, I’d say that Nepomuk is probably the best place to start (unless you are already familiar with the Virtuoso codebase). There are plenty of bugs to fix and performance improvements to be made there.

  9. Luis said

    At some point I heard about the possibility of showing IM conversations in kmail, just as they are shown in gmail. Is this still in the plans? Also, I have been compiling from source and the only thing that prevents me from using telepathy-kde full time is the plasma-widget not working. Do you have any plans for a previw release? I would definitely be an early adopter.

    • grundleborg said

      We’re planning a preview release quite soon now (max 2 months away), but it will be missing most of the Nepomuk magic since this still has quite a long way to go to be usable. As for the KMail feature, I’m not personally aware of this feature being planned, but this is just the sort of thing that would be very easy to do with our Nepomuk integration in place.

      • That KMail feature is the icing on the cake of my GSoC project propsal 😉 How could you forget from yesterday’s discussion?? 😛

      • grundleborg said

        Oh I see, sorry… I was thinking of it as showing the conversation history, rather than presence info, and it didn’t occur to me that you were proposing to do conversation history in KMail too 🙂 Nice one.

      • Oh..uhm…ok, forget that, I’m an idiot 😀 Of course it is conversation history! I read KMail, IM and GMail, therefore automatically assumed presence info. My bad 😀

        But sure, once the loggerNepomuk integration is done, that shouldn’t be too hard. Does KMail actually support conversation display though?

    • grundleborg said

      Oh, and someone’s working on the Plasma applet at the moment, so hopefully it’ll be working again soon.

  10. Govi said

    The problem with nepomuk is on mobile. AFAIK there is no nepomuk support in KDE Mobile. I think nepomuk could be good for integration of collaboration in applications but i think KDE SC still need telepathy-based traditional IM

    What about performance? I think Nepomuk was designed to store static data, not dynamically changed contact status, wasn’t it?

  11. kkszysiu said

    Well, we could use Telepathy + QtFolks + KDE PIM to archive your idea on KDE 🙂

    • grundleborg said

      You could realise a *single bit of integration* like that. The point of Nepomuk is since pretty much every KDE app integrates with it, information can be related across functional domains. Folks + KDE PIM would just give you the same things we had in KDE3 times with KIMProxy. With Nepomuk we can link everything related to people together. E.g. files that you collaborated on with someone are related to that person (or even documents they sent you). The features of Folks are basically just one ontology (NCO) from Nepomuk.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: