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)

KPeople

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 brainstorming

I agree and disagree with David (I'm seriously just brainstorming here, I don't know where I want to go with this), there is actually nothing that cannot be done without writing everything into nepomuk, but at the same time it might be easier to make just sparql queries on nepomuk than using telepathy and nepomuk at the same time

For example let's say that I want all the persons that are online and that have a certain capability. If the app is using the models with the filters in the library it won't be a real problem, but if it is using Nepomuk directly it might be difficult if data is not on nepomuk

Now the problem is if this is a real use case, why should one query for certain capabilities just to display it? The most probable use case is that one wants to know if a user has a capability to start an action on that user. But if it does it will need to link the library anyway, so it doesn't get any advantage from using Nepomuk directly.

On the other hand an application could just display the data, for example a krunner could show you all the games that you can play in that moment online with a friend, and just start the game when you click it and the game could start and ask you which of your online friend (with that capability) you want to play with.

Temporary data vs. permanent

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

One of the problem with temporary data stored in Nepomuk is that it is persistent. Therefore, for example, even when you are offline, if telepathy-nepomuk-service is not running you continue to see your contacts as online. Telepathy nepomuk service should know which data is persistent and which is temporary, and always delete or mark as invalid the temporary data when telepathy is not running, or when a certain account is not connected.

If we really want to save this kind of data, in my opinion we should go for a separate storage.

@vHanda Is it possible to save this kind of volatile data in a separate graph? Or even better one different graph per account? In this way it should be much easier to cleanup all this data when one account goes offline, and it is easier to figure out if that data should be invalidated. There could be some metadata attached to the graph that tells Nepomuk that the graph is temporary and therefore should be deleted, together with all the data contained at Nepomuk startup

vHanda: Store volatile data in a separate graph - Yes. But it is not possible to store them in some kind of in-memory storage. We had a discussion once where the nepomuk-storage service would monitor the volatile applications ( via dbus ), and the moment they go down, delete the graphs they created. We didn't get around to implementing it, as it wasn't really a priority.

I honestly think we're micro optimizing right now. We should concentrate more on features.

Current data vs. historical data

So let's admit that Nepomuk 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

vHanda: Speaking as a Nepomuk developer - Nepomuk isn't that great for storing massive amounts of information like logs of when contacts were online and offline. It's just too much information. Zeitgeist is more suited towards this task. I want to store chat logs in Nepomuk, but not every trivial stuff like when the presence, capabilities, etc change.

drdanz: About chat logs, importing them in Nepomuk will probably mean that we will have the same data in 2 different place (TpLogger logs and Nepomuk). Are you fine with that?

vHanda: Well, I heard something about you guys storing them in an sql lite database. So, I'm not too fond of that. I need the chat logs to be there in Nepomuk, if you guys want to also store them in your TpLogger, that's up to you guys. I like having the *entire* chat log in Nepomuk - http://vhanda.in/blog/2012/01/chat-logs-in-nepomuk/ . Plus there is also the fact that meta-contacts are going to be done via Nepomuk, so you ideally would want to display a conversation history based on contacts and not based on accounts.

Plus, by saving chat logs in Nepomuk, we can *theoretically* analyze them to see who you talk to more frequently and adjust the contact lists accordingly.

More About Zeitgeist

For this kind of data only the current value should be saved in Nepomuk, but Zeitgeist seems to be a very good candidate to store historical data. There is a Telepathy backend for Zeitgeist (that at the moment requires to be ported to vala) and Zeitgeist can push data into Nepomuk doing some filtering magic.

If I understand correctly, Zeitgeist could store internally the events (i.e. foo's status at 3:15PM changed to busy) and set the presence status in nepomuk

vHanda: Considering that there is no Zeitgeist-Nepomuk backend right now. How about we stick with the Telepathy-Nepomuk service? Specially since it works! In the future when someone (not me) has implemented pushing of events from Zeitgeist into Nepomuk, we can then switch.

Right now, lets stick to what we have.