KTp/RepeatedDiscussions/Nepomuk

Why are you planning on using nepomuks for Contact Aggegation

Rationale

What we require in KDE workspaces with regards to contact storage (from KTp's view)

• A way to store contact rosters when we are offline

This is desired to stop showing empty lists in the contact list, having dynamic search results etc.

• A way to associate multiple contacts together

Metacontacts!

• A way to link a contact with an email address so we can email a contact if they are offline

And ideally other contact information, setting a preferred Alias or Avatar or even just fetching higher resolution avatars *cough* Facebook XMPP! *cought*

• A way to show presence information from within KMail and start chats and other actions

From a birds-eye KDE perspective as a whole, solving metacontacts is a bigger issue not just KTp related: We have people with multiple email addresses in kmail; we might want avatars in kmail, to associating files/attachments with people for better searching. We also want to allow for other clients, such as the Skype (boo!) to integrate as well into the desktop as we do.

So we need?

• We need a common database with a shared but extensible schema

• We need everyone to be able to feed into this database without knowledge of other components

• We need that database to handle multiple clients reading/writing at once and tells us when things change

This is exactly what nepomuk does.

I don't use Nepomuk

For the time being libkpeople will be an optional dependency in KTp. Optional at both build and run time. However you will not get any of the new features.

Whilst Nepomuk will be required for new features, file indexing (the generally slow part associated with Nepomuk) is not.

I still disagree

All other options were fully investigated and researched before making this decision, with people who have been involved in this for a long time. We are not interested in discussing it again. We also do not want to duplicate work in multiple backends.