Contact Aggregation [was: KDE Telepathy on its way to Extragear]

Daniele E. Domenichelli daniele.domenichelli at
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 [1] and [2] 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[1] 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 
a problem.

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 
aggregate contacts.
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 mailing list