KTp/Tasks/Metacontacts

Metacontacts

Goals

• Merge contacts from various contacts (i.e same person on Facebook + Jabber) appear as one entry in the list.
• Still see individual contact information, start chats with contacts.
• From within a chat, select a different account to talk to the same person.
• Optionally show names/avatar from KDE PIM sources as well as Tp.
• KDE Telepathy needs to STILL WORK when nepomuk is disabled, but I'm happy for it to not have metacontact support etc.
• Support whatever KDE PIM want us to do. We need to integrate with them as much as anything else.

Library Use Cases

Contact List

We need a model of all people, with child nodes for each contact.

Handlers

From a handler (text-ui) POV we need to be able to get a person from an individual Tp::Contact. This should NOT load the entire model then search for the correct person. I want a nepomuk person from a Tp::Contact.

Outside KTelepathy

I think everything will be pretty much the same "all people" or "give me a person with this ID". The only difference with the latter is we will want "give me the nepomuk contacts, and therefore Tp::Contacts with this nepomuk ID.

Main Plan

This is a copy of George G's plan

http://grundleborg.wordpress.com/2011/04/26/kde-telepathy-a-vision-for-integration/

In short:

• A nepomuk service monitors KDE Telepathy.
• Syncs ALL telepathy data into NCO:Contacts
• These have relationships to make PIMO::Persons
• We have a library that pulls stuff out of nepomuk and is the basis of the contact list.
• Tp::Contacts are looked up in the client library from the PIMO::Person.
• All actions are handled inside the client library (start chats etc)

Dave's Proposed Mods

Dave's Arguments with the existing plan

• There's no point syncing _all_ telepathy data to nepomuk as some sort of abstraction layer. We have up-to-date data available juts over dbus, why read some potentially old stuff out of a database.

vHanda: Right now there is about a 200ms lag between the Nepomuk Database and Telepathy. I've done that so that we can cache multiple requests.

• We are constantly syncing every piece of information to a database regardless of whether anyone is actually looking at it or not.

  vHanda: We have no way of knowing if someone wants that data or not. Anyone could be using Nepomuk.

• The client library then becomes massive and a pain to maintain (we need every method from Tp::Account)
• The argument for this approach I always hear is "it allows you to start a text chat from inside digikam (for example), however
  1. I've never wanted to do that.
     mck182: There is a valid use-case.
  2. You'd need to write IM specific code in digikam to know how to display the status from PIMO::Person, at which point you haven't saved yourself anything from having to write telepathy code. You only care if you can start a telepathy file transfer if you're writing teleapthy code, so why check from a cached version in a database.
     mck182: Not really.Writing the IM specific code is just a matter of one switch for choosing the correct icon. Even that could probably be moved right into Nepomuk, so there would be no need to write IM specific code anywhere.
• It has a nepomuk dependency, and given nepomuk's reputation (deserved or not) we can't have this.
  mck182: Or we can help it.
• Data duplication is generally bad.
  mck182: With this one I have to agree.

Dave's slight tweak to the proposed plan

• We still export NCO::Contact
• We still link them into PIMO::Persons
• NCO::Contact only has the bare minimum, accountID, contactID, alias, name. This still allows it to be joined. Not telepathy specific parts like capabilities.
• All actions are done in telepathy, not abstracted.
• We build a model that links Tp::ContactPtr's to PIMO::Persons
• In the model we display information from nepomuk if there is any, if nepomuk doesn't exist - No problem.
• Basically it's the same but reversed. Instead of putting everything in nepomuk and mixing Tp stuff when we need it, we look at Tp stuff, and grab nepomuk stuff if it's available.

Reasons

• It's less wasteful, and always up-to-date/right.
• If they don't have nepomuk it still works.
• I prefer it, and I'm always right.