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

[Martin Klapetek]

On Fri, Jan 6, 2012 at 20:44, Daniele E. Domenichelli <
daniele.domenichelli at gmail.com> wrote:

> On 06/01/12 12:40, Martin Klapetek wrote:
>
>> Nevertheless we later attended the libfolks talk and
>> it is pretty much the same as Nepomuk's PIMO:Person, except that Nepomuk
>> is
>> a broader and general platform while folks concentrate solely on contacts.
>> And given the effort to integrate Nepomuk more deeply into KDE Workspace,
>> we simply chose to go with Nepomuk.
>>
>
>
> It is not exactly the same as PIMO:Person, you are confusing a
> representation of something with a class + algorithms to handle something.
> You might compare want to compare Folks to the library that George Goldberg
> was writing, but we have being waiting for this library for a lot of time
> now, and afaik the library is in a bad shape at the moment, George was
> planning to make a lot of changes to the library but he is currently
> inactive. Moreover you told me that we miss some major feature in nepomuk
> (watching for property changes) so that will delay even more the
> availability of the library.
>

True that. As for the library - that's what I'm working on right now (after
designing it in Cambridge with George) and it's pretty much working (you
can already start chats with no problems, I'll show you next week). The
missing Nepomuk feature is already in review [1], but that's only for IM
use anyway, it does not break using PIMO:Person for address book for
example.


>
> I am not suggesting not to use Nepomuk, I am suggesting not to use it for
> _creating_ new information but just to _extract_ information created
> somewhere else (i.e. by folks)


But there's no point in duplicating the data. If you use folks, why put its
data then into Nepomuk in the first place? Everything that would need
contacts could deal with folks directly. Right now you are able to feed
your data to the Nepomuk directly - both from Akonadi and from Telepathy.
Folks would just add unneeded layer between that (ie. akonadi+telepathy -->
folks --> nepomuk; whereas right now it's akonadi+telepathy --> nepomuk).

I personally think that if we would focus on improving the feeders rather
then implementing folks everywhere, we would end up with better solution in
the longterm.

[1] - https://git.reviewboard.kde.org/r/103522/

--
Martin Klapetek | KDE Developer



>  Daniele
>
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/