[Kde-pim] Re: GSoC Idea - Integrating with Nepomuk Person and Telepathy

Volker Krause vkrause at kde.org
Wed Mar 30 17:37:03 BST 2011


Hi Martin,

On Sunday 27 March 2011 18:09:01 Martin Klapetek wrote:
> my name is Martin Klapetek and I've been working with kde-telepathy team for
> past few months. The ultimate goal of kde-telepathy team is to get
> Telepathy deeply integrated into KDE.
> 
> Today we discussed some ideas and it came to my mind, that it would be great
> to have Telepathy integrated with PIM. The main idea is to see the online
> status of your contacts inside PIM apps like KAddressBook, Kontact, KMail
> etc. and also a possibility to start a chat/video/audio call over Telepathy
> (we'll be doing a pre-release of basic Telepathy components soon). With
> this idea we came to talk about how it would be possible and George
> Goldberg of kde-telepathy hinted, that it was a "dream" to integrate
> PIMO:Person into PIM for some time. And the Person class would be just a
> great way for integrating the online statuses and the rest of Telepathy
> stuff.

yes, that's definitely something we want to have :)

> So the GSoC project would basically include integrating Nepomuk's
> PIMO:Person into KDE PIM and then integrating KDE PIM with Telepathy with
> the PIMO:Person approach.

well, it's not that easy ;) Here are some things to consider:
- currently we create NCO:PersonContacts objects in Nepomuk for every vCard 
contact, email recipient/sender, event attendee, etc we encounter. These need 
to be aggregated into PIMO:Person objects. This includes finding 
NCO:PersonContacts that refer to the same person as well as ignoring entries 
that are no person at all (spam, mailinglists, etc). Otherwise you'll end up 
with quite some useless garbage in the addressbook.
- a way to manually merge PIMO:Person objects that actually refer to the same 
person but the software couldn't detect it automatically. This includes 
dealing with conflicts etc.
- some of the NCO:PersonContacts refer to vCard contacts that are actually 
writable, so when changing the corresponding PIMO:Person we need to write back 
those changes (so it's propagated back to eg. the groupware server they came 
from).
- porting KDE PIM to be PIMO:Person based is a huge task, for kaddressbook it 
would basically be a full rewrite of the application

Hm, if we don't go for the full port but just augment the contact display by 
the online status retrieved from the PIMO:Person object in the first step, we 
can skip the write back problem for now, as well as many changes to the 
applications, making this actually doable within a GSoC project.

> What do you think about this idea? 

I like it, but it requires some more detailed definition on what is part of 
this project, this topic can easily get way too big for a single GSoC project.
But working on the foundations of the PIMO:Person-ification would be a very 
welcome project IMHO.

> Also would someone be willing to mentor?

yes, I'm interested in (co-)mentoring a project in this area, I can at least 
cover the KDE PIM side, but I lack the in-depth Nepomuk knowledge to cover all 
of this. But I'm sure we'll find support from the Nepomuk team for this :)

regards
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110330/62961990/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/


More information about the kde-pim mailing list