<p><br>
On May 2, 2011 3:43 PM, "George Goldberg" <<a href="mailto:grundleborg@googlemail.com">grundleborg@googlemail.com</a>> wrote:<br>
><br>
> On 2 May 2011 13:38, Vishesh Handa <<a href="mailto:handa.vish@gmail.com">handa.vish@gmail.com</a>> wrote:<br>
> > Hello List<br>
> > This year we have a KDE PIM and Nepomuk related GSoC project [1] - PIMO<br>
> > Integration. The student - Martin Klapetek, his mentor - Volker Krause, and<br>
> > I, had a meeting[2] this Sunday to discuss how he would go about<br>
> > implementing this. This is a short summary of the meeting.<br>
> > Martin's project consists of linking all the appropriate nco:Contacts with<br>
> > pimo:Persons, merging duplicates, and propagating the changes made in a<br>
> > contact up/down the chain. Here the chain would be PIMO -> NCO -> Akonadi.<br>
> > nco:Contact and Akonadi have a 1:1 mapping, but pimo:Person and nco:Contact<br>
> > would obviously have a 1:n mapping.<br>
> > It was decided that a new Nepomuk service could host all the related code.<br>
> > This would include the initial scanning for duplicates, and<br>
> > change propagation. The change propagation will require us ( Nepomuk<br>
> > developers ) to create a more appropriate resource watching mechanism.<br>
> > Is everyone okay with this? Or does anyone have any other ideas?<br>
><br>
> Just checking, but does your design take into account that not all<br>
> NCO:Contacts originate from Akonadi (I'm thinking Telepathy,<br>
> obviously)? These nco:Contacts should still be included in the<br>
> automatic adding to PIMO:Persons etc.</p>
<p>Yes, I'm counting with that in the design ;)</p>
<p>--Marty </p>
<p>><br>
> --<br>
> George<br>
> _______________________________________________<br>
> Nepomuk mailing list<br>
> <a href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</p>