Moving forward in the RT communication project - some issues
drf54321 at gmail.com
Sat Mar 27 23:53:02 CET 2010
for the list: I'm a new developer into kde+telepathy and I'm working with
George to make everything happen. That said.
I started to work on the contact management part in contactlist. As agreed
with George, the steps would be:
<drf__> the clients talk to telepathy to add/remove accounts, change groups,
<drf__> they just take care of error handling, and upon success they do
<drf__> t-i-d listens in the background, and whenever it picks a change, it
updates nepomuk accordingly
<drf__> clients will be listening to nepomuk changes and will update their
However, this has more flaws than I initially thought. contactlist has no
knowledge of telepathy at all, and hence it's not able to associate a contact
resource to a telepathy contact directly. This means that to implement such a
functionality, a client would have to reimplement a big part of the whole
logic behind telepathy-integration-daemon to be able to act upon Tp::Contacts,
which is probably not what we want.
So I thought about a possible solution: having a small wrapper library that
would serve as a bridge between $client and telepathy-integration-daemon. This
library would act upon a DBus interface which would be provided by t-i-d, and
all the logic would be abstracted there. So in your client you would have to
use an interface like:
KTelepathy::addContact(const QString &id);
KTelepathy::removeContact(const QUrl &uri);
This thing is more or less something like libempathy (even if it's aimed to
solve a different problem), and I think it would be worth to have.
This would mean that:
1. All the logic and the interaction with Telepathy-qt4 would be handled by t-
i-d and a client should never use Telepathy-qt4 directly but the high level
KTelepathy (or whatever the name)
2. The clients will be totally based on Nepomuk resource URIs and will
interact with KTelepathy (or nepomuk itself) just being based on that - t-i-d
will take care of mapping a URI to the right Tp::Contact.
I like this approach, however we need to see if we will ever need to use Tp-qt
inside our clients (I'm mostly thinking about chat, audio, video) and if it's
worth adding yet another layer.
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-telepathy/attachments/20100327/ddd32e23/attachment-0001.sig
More information about the KDE-Telepathy