Current Status

KIMProxy structure Integration of presence is currently done with the help of a DCOP interface called KIMProxy.
Basically each contact is associated with an addressbook entry. That integration with the KDE address book is done with a shared library: KABC

If an application like KMail want to know if a particular contact is online, it will ask to each application that support KIMProxy if they know that contact, and will request his status thought DCOP functions. Same if it want to send a message.
Konqueror may also request the list of all contact that may receive file, and can give the KIMProxy compatible application an URL to send to a contact.

Notice there is no need of a daemon (just dcopserver), and it work with Kopete, but also with konversation, or all others IM application out of there that support KIMProxy, even if they are running in the same time

The Now Listening feature is done with a plugin which extract the song of some media player, most used media player are supported. There is currently no common DCOP interface to do that.

Telepathy

Telepathy structure One of the problem of the KIMProxy is that it is not portable outside KDE, for the following reasons:

  • It uses DCOP, which is reserved to KDE
  • It require unique contact identifier, that are kabc contacts in the case of KDE

The first problem doesn't exist anymore in KDE4 since we switched to D-Bus, and the second problem could be solved with a common address book, or with dynamic identifier.

But guys of the others desktops have made their technology, namely telepathy
They have splitted everything in separate process, each communicating with D-Bus interfaces. There is a global daemon, the Mission Control, which centralise and dispatch everything.
Their current implementation also involve a second daemon (galago) that i have not represented on the schema, but which could be placed between desktop applications (KMail, KAB) and the mission control. His role is to aggregate presence. KDE Application would not need it

I have made a comparison with both approach

KIMProxy Telepathy
No daemon required Require Daemons Daemons are bad because of performance (everything need to be passed thought D-BUS) and they introduce unnecessary complexity
If a protocol crash, all Kopete crash If one connection manager crash, everything else still works, and the broken process may be restarted
The user need to change the whole client if he want to change the interface The user may change the interface But it is also possible to write interface plugin with Kopete
One need to code each protocol supportOne can re-use connection manager of others client We can use library anyway, and most protocol are already coded in Kopete
We just need to port Kopete to Qt4/KDE4We need to do important change in the design which almost consist of rewrite Kopete from scratch

We could imagine an hybrid solution, in which Kopete would be both the mission control, the connection managers and the UI. In the same process. It would just export the telepathy interface that are equivalent to the KIMProxy ones.
There could be a "telepathy" protocol that connect with others connection managers. and a "telepathy" plugin that export Kopete as a connection manager
But this is just the KIMProxy model, with a telepathy compatibility layer.

XMPP

XMPP structure Let's now propose a new, probably very controversial idea.
This approach not very realistic as it, but can be combined with the above to get great results
It is based over XMPP, the Jabber protocol.

As you might know, unlike others protocol, Jabber let you make several connexion to the server. So instead of having one connection shared with all applications, each applications connect to the XMPP server.
This can be done with a light library. Connections are possible without sending presence information, or downloading the roster. An application could use directly use the powerfull PubSub mechanism

So KMail and KAdressBook would connect to the Jabber server in order get presences. Amarok would connect the user tune, and Konqueror for the web authentication.

For starting chat with a contact, a XMPP URI could be used to open the chat window, exactly like mailto: URI start the email editor.

The main problem of that approach is that it would work only for jabber.
Fortunately, there are gateways. But gateway require to register to a Jabber account, even if one does not use Jabber.
I personally believe that Jabber is the only future protocol. So in the long term, I think this is a good approach

Several question need to be answered:

  • How to share the account and password between applications ? Probably with the help of global config and KWallet
  • What if the user has several Jabber accounts ? There is none Jabber-to-Jabber gateway yet
  • Is a XMPP connection not too heavy for very simple tasks, even if they may be very light ?

So this model is maybe not realistic in the short term. But it is not incompatible with the previous ones, they can be implemented in the same time, or later, and be in use for some cases and not for others.