Wasn't using folks for contact aggregation suggested few months by Paolo Capriotti? If I remember the idea was dismissed (I am not able to find the discussion between him and G Goldberg), but there were few who were receptive. I think the guy also made a scratch repo.
It will be great to use a framework which works for both KDE and GNOME and it seems folks is deeply integrated into GNOME Date: Thu, 05 Jan 2012 13:25:53 +0100 From: "Daniele E. Domenichelli" <[email protected]> To: KDE Telepathy <[email protected]> Cc: KDE Core Devel <[email protected]>, KDE PIM <[email protected]> Subject: Re: Contact Aggregation [was: KDE Telepathy on its way to Extragear] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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. Cheers, Daniele [1]http://lists.kde.org/?t=132484853900001&r=1&w=2 [2]http://lists.kde.org/?t=132560539100005&r=1&w=2 [3]http://telepathy.freedesktop.org/wiki/Folks ------------------------------
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
