Moving forward in the RT communication project - some issues

George Goldberg grundleborg at googlemail.com
Sun Mar 28 00:21:38 CET 2010


Hi,

2010/3/27 Dario Freddi <drf54321 at gmail.com>:>

<snip>

> 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.

Having discussed this further with Dario on IRC, we have concluded to
go the following way for now:

- Don't develop any library yet, but make it easy to move stuff out
into one later as needed.
- We can already figure out the contact identifier and the
corresponding account from data in Nepomuk, which is all we need to
get MC to start a new channel.


George


More information about the KDE-Telepathy mailing list