Contact Aggregation [was: KDE Telepathy on its way to Extragear]
Daniele E. Domenichelli
daniele.domenichelli at gmail.com
Thu Jan 5 12:25:53 GMT 2012
Sorry for cross-posting, but there are 2 parallel threads going on about
this issue on 3 different mailing lists, please refer to  and  if
you missed something.
On 25/12/11 22:39, Ben Cooksley wrote:
> Please ensure you store the main copy of the data somewhere outside
> Nepomuk. In a large number of user support scenarios, especially those
> involving an inconsistent Akonadi, it is necessary to destroy the
> Nepomuk database to ensure ghost entries do not cause problems.
> If KDE Telepathy uses Nepomuk as it's primary store of contacts
> information, it will make user support for other areas of KDE which
> are still maturing much harder.
> There are also a number of users who have Nepomuk disabled, or a
> system where Nepomuk is broken (due to old configurations, corrupt
> databases, and the like).
This is one of the reasons why I was wondering if using Folks for
contacts aggregation is a better idea than using Nepomuk directly
I still believe that is very important to expose this data trough
nepomuk, but I'm a little concerned that handling this directly might be
My idea is that we should push the data to folks and write a
nepomuk-folks-service to pull data into nepomuk database. In this way we
can still query nepomuk database like if we write data there directly,
but we will handle aggregation using a library whose only aim is to
Moreover this means that applications not using Nepomuk will still be
able to access this data.
Folks backend for telepathy is already existing and it would be possible
to write a Folks backend for akonadi, meaning that we will just need one
nepomuk-service to import aggregation data. At the same time if a user
wants to use non-kde stuff like evolution or empathy, on nepomuk we will
have the same information from all the sources.
I'm quite interested in knowing what do PIM and Nepomuk people thinks
about this, since I really believe that whatever way we choose to do it,
we must choose it together.
More information about the kde-core-devel