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.

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.

Outside KTelepathy

I think everything will be pretty much the same "all people" or "give me a person with this ID", now let me do telepathy things.

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 pimo::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.
- We are constantly syncing every piece of information to a database regardless of whether anyone is actually looking at it or not.
- The client library then becomes massive to maintain (we need every ensure... 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. 2) You'd need to write IM specific code in digikam to know how to display the status from PIMO::Contact, 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. 
- It has a nepomuk dependency, and given nepomuk's reputation (deserved or not) we can't have this. 
- Data duplication is generally bad.

Dave's slight tweak to the proposed plan

- We still export PIMO::Contact
- We still link them into PIMO::Persons
- PIMO::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.