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.

Dr. Danz's quick brainstorming before leaving

(I will add more later, sorry I'm in a hurry)

Temporary data vs. permanent

Nepomuk is a great place for storing permanent data. But is it for *temporary* data (presence, capabilities, ecc)

Current data vs. historical data

So let's admit that it is good for temporary data, is it good for recording the history of the data?

For example

• How do we remember that foo had the display name as "Mr. Foo" and then it changed to "Foo the Fool"?
• How do we know that one person had one capability and now it doesn't, so that we can remember him to close pidgin and start telepathy-kde?
• How do we know at what time a person is usually online

Options:

• We just forget about that (probably a good option)
• We let someone else handle that (i.e. Zeitgeist)
• We handle it in Nepomuk, but requires changes to the ontology and a lot of crappy stuff in the database