[Kde-pim] Akonadi/Nepomuk integration with Telepathy

Tue Sep 15 20:51:44 BST 2009

Hi,

On Monday 14 September 2009 23:46:26 you wrote:
> First of all, sorry for the cross-posting. I'm not quite sure of the
> best way to address Akonadi and Nepomuk developers together.
> 
> I've been involved with Telepathy for about a year and a half, and for
> most of that time, on and off, I've been considering the question of
> if/how/why/when/etc Telepathy should interact with Akonadi and
> Nepomuk. Every time I have a discussion about it, I leave thinking I
> know the answer, but always before I complete any implementation I
> find myself doubting whether I am doing the right thing. I'd like to
> try and solve this once and for all, so here goes.
> 
> What is Telepathy?
> ----
> Telepathy is a framework for real-time communications, ie. Voice over
> IP or Instant Messaging. It is a DBus based framework with a central
> daemon managing all the connections to different IM networks allowing
> multiple applications to access the same connections. This allows for
> a previously non-existant level of integration into the desktop
> environment of Instant Messaging, e.g. Kopete for text-chats, a plasma
> presence chooser, collaboration features in KOffice etc etc...
> 
> Telepathy is also a cross-desktop technology. It is widely used in
> Gnome already, and hopefully will soon be widely used in KDE. It is
> worth noting that both I and the Gnome Telepathy developers are keen
> to keep as much of the Telepathy infrastructure desktop-independent as
> possible - that includes where possible implementations as well as
> specifications.
> 
> What PIM-related information does Telepathy Provide?
> ----
> There are two bit's of information that Telepathy provides that I
> believe are related to PIM.
> 
> The first is the Contact List. I imagine this is similar to a contact
> list from a groupware server. It is returned by the Telepathy API as a
> vcard for each person in your contact list, and in some of the
> supported protocols (e.g. Jabber), it returns a lot more information
> than just a id and name.
> 
> The second thing it provides is presence information, ie. is this
> person online/away/busy/etc.
> 
> How might this information interact with other KDE-PIM applications?
> ----
> The vcards provided for the contact list might make sense to display
> in KContactManager. I'm not sure. I do know, however, that experience
> in Gnome suggests that trying to merge/sync vcards in my personal
> address book with my Instant Messaging server contact list vcards
> leads to disaster. This means that the vcards for Jabber contacts and
> their local entry in the local address book should be kept
> separate.
> 
> As for the presence information, I imagine that might be a nice thing
> to display alongisde people in KContactManager?

The display of presence information is something that we actually had in KDE3. 
KAddressbook and KMail both displayed the online status of a contact and had 
easy ways to start a chat. This was done by a generic DCOP interface in 
kdelibs, called KIMProxy. Kopete (and Konversation?) implemented that 
interface.
That interface still exists at trunk/KDE/kdelibs/interfaces/kimproxy, but I 
think it is pretty much dead. Because it was dead, I removed the KMail usage 
of it in r706534.
Something like this based on Telepathy would be quite nice, but I don't see 
that Akonadi or Nepomuk would be used here.

> Where does Nepomuk fit in?
> ----
> This is where, for me, it starts to get very confusing. I'm really
> struggling to see what the relationship between Akonadi and Nepomuk is
> supposed to be. For instance, will KContactManager be Nepomuk aware?
> 
> Nepomuk has this notion of a person, which seems the perfect way to
> handle the multiple-vcards for one physical person situation. You have
> multiple vcards linked to one Person entity. However, what concerns me
> is that feeding Telepathy contacts straight into Nepomuk might bypass
> KDE PIM applications using Akonadi to store vcard files.

Akonadi feeds all the contact information it has to Nepomuk. Akonadi itself is 
a cache/proxy for PIM data such as contacts, which can come from multiple 
sources, like local iCal files or remote Exchange address books.

Since Akonadi feeds that contact data into Nepomuk, it can use Nepomuk to do 
semantic searches in those contacts. We mainly use Nepomuk to make use of its 
powerful search functions.

As far as I understand, Nepomuk can deal with persons/contacts on a higher 
level, with PIMO¹. The idea of PIMO is that you have one single entity 
representing a real person contact. That 'real' person is then linked to the 
contacts which Akonadi and Telepathy might store in Nepomuk. So you can have a 
"John Doe" person in PIMO, which is linked to the "John Doe" from the Exchange 
server, which is fed into Nepomuk by Akonadi, and the "John Doe" on my Jabber 
list, which is fed into Nepomuk by Telepathy.
However, for me, it is totally unclear how the 'real persons' are going to be 
edited, and where they will be used. As far as I know, there is simply no 
application doing that at the moment. There is a bit of duplication here: 
Currently, the KDEPIM applications use Akonadi to access contacts stored in 
Akonadi, so storing contacts directly in Nepomuk would indeed bypass Akonadi. 
Will the applications in the future access PIMO contacts instead? I have no 
idea, and this is a bit complicated topic.

Tobias suggested writing an Akonadi resource that can read the Telepathy 
contacts, which is a great idea to get KDEPIM applications see the Telepathy 
contacts. Akonadi would also feed those contacts to Nepomuk, so they would be 
available for semantic searches as well.
However, Akonadi has no concept of 'real persons' or meta-contacts, unlike 
PIMO. So everything is a bid murky here.

Consider the above just as thinking out loud/a brain dump, I don't really have 
answers to any of those questions.

Regards,
Thomas

¹ http://dev.nepomuk.semanticdesktop.org/wiki/PimoOntology
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090915/3dd74657/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/