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