Moving forward in the RT communication project - some issues

[Dario Freddi]

Hi there,

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, 
and stuff
<drf__> they just take care of error handling, and upon success they do 
nothing
<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 
interface accordingly

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);
etc

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.

Thoughts, comments?

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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