KTp/Tasks/KopeteLogs

Integrating Kopete Logs

The problem/backstory

We have logs in Kopete, we have our own logs. We can't "throw away" the old data.

There is a log program provided telepathy-logger in 0.2 this had an XML file backend, in 0.3 this is moving to MySQLLite.

Telepathy-logger also loads Pidgin logs by a plugin that reads from pidgin files as well as the telepathy logs.

Options

Nepomuk all the things (importing from TpLogger)

We write something that logs Tp Chats to nepomuk, and imports telepathy stuff to nepomuk.

Problems: We don't know when to import things from TpLogger, unless we constantly just poll it. Logs are duplicated in two places.

Nepomuk all the things (with our own logger)

We write something that logs Tp Chats to nepomuk, and imports telepathy stuff to nepomuk.

Instead of relying on TpLogger we make our own logger as a nepomuk service text observer.

Problems: If you disable nepomuk at any point you won't get logs for that period. Also if you have tp-logger as well logs are stored in two places completely independantly.

Nepomuk all the things (as a storage backend for TpLogger)

Problems: I have literally no idea how to do that. I believe it would have to be in Tp-logger.

Akonadi all the things

From my understanding of Akonadi this is a far more sensible place for logs.

There is already code for importing Kopete logs AND Logs from Telepathy-logger (old bindings). George G mentored this project and seems to think there's something wrong with it.

It still has all the variants as above, and with all the same advantages/disadvantages.

Additionally if we have all this akonadi feeding to nepomuk which is currently being done everything is stored in /3/ places.

Either nepomuk or this could be merged with other people's code for pulling logs from other places (such as GTalk logs from GMail (Vishesh has sample code for nepomuk) or Facebook messages (which Akonadi supports)

Discussion

Dave: The situation with what goes in nepomuk and akonadi is a complete arbitrary mess based purely on what the developer prefers rather than any actual decision about the data. Which means we have additional data going into both places.

This whole idea of copying from akonadi to do neopmuk is completely retarded (/political). You can do a full text search in MySQL. One of them needs to just die. </unhelpful rant>

Merge inside TpLogger

TpLogger has a set of plugins for fetching data from various sources. We make one for kopete.

This is how Pidgin logs are loaded.

Problems: code would have to go in tp-logger. We'd need to write it in glib. I don't know glib.

Merge at the Ktp-log-viewer level

Instead of grabbing the two sets of data and merging them at the data level it could be done at a view level. In KTp-log-viewer we load data from Kopete, and we load data from TpLogger. Job done.

Discussion

Dave: This or above are by far my favourite. It's simple. Job done. We don't touch the data, we've less chance to break it. However we can't do any fancy merging with additional data sources, but does that actually exist?

Screw Kopete Users

Simplest option. Don't import, live with the hate, 2 years later they'll forget.