KTp/RepeatedDiscussions/Nepomuk: Difference between revisions

From KDE Community Wiki
(Created page with "Why are you planning on using nepomuks for Contact Aggegation ==What we require in KDE workspaces with regards to contact storage (from KTp's view)== * A way to store contac...")
 
Line 1: Line 1:
Why are you planning on using nepomuks for Contact Aggegation
Why are you planning on using nepomuks for Contact Aggegation


==What we require in KDE workspaces with regards to contact storage (from KTp's view)==
==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
* A way to store contact rosters when we are offline

Revision as of 11:40, 16 May 2013

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, file indexing (the slow part of 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.