Pim Sprint - KPeople Summary

[Vishesh Handa]

Hey guys

After the PIM sprint, David, Martin and I discussed searching with respect to 
KPeople. We have the following problems -

1. Searching for a contact gives duplicates since the same contact can exist 
in multiple address books.

2. When searching for a contact you want to be given the final aggregate 
contact, this should take the following into consideration -
	* Akonadi Contacts
	* Telepathy Contacts
	* Custom user fields which have been added in the contact

--

Currently KPeople has a concept of plugins and does the aggregation, this 
aggregation is saved in a simple sqlite db. It's fairly trivial. The 
additional custom user-fields are saved in a vcard in a special akonadi 
resource.

The initial idea discussed was for KPeople to aggregate all the contact info 
into one vcard, store that, and index it. This would however result in KPeople 
having to deal with synchronization issues if a contact is updated in Akonadi 
/ somewhere. We don't want to deal with synchronization.

The final idea is for KPeople to install a special Baloo search plugin which 
would search over all the required databases, aggregate the contacts and give 
the results. Since everyone is using Xapian to store the index, this should be 
do-able. Xapian allows searching over multiple databases and collapsing 
multiple results based on some custom criteria.

--

Another problem is showing extra information during email completion. We could 
not figure out a solution for this as email auto-completion is a special case 
which has its own custom database.

--

Providing a runner for searching these KPeople contacts was also discussed, 
however given that KPeople is highly dependent on Telepathy and KDE-PIM, and 
Plasma is now on Qt5, the solution is not obvious. 


-- 
Vishesh Handa