[Kde-pim] Releasing libkpeople 0.2.0

[David Edmundson]

>>
>> Current Problems:
>>  - Groups.
>>     - KABC::Addresee does not have a field for groups. In Akonadi
>> terms contacts are from a given contactGroup passing and merging trees
>> from all the sources will make things much much more complicated for
>> everyone. My intended plan is for datasources to provide groups as a
>> vcard role (internally only), and the client can then do what it wants
>> with them. Right now I abuse the VCard Category property. It turns the
>> Akonadi data on it's head.. not sure if you would like that.
>>
>
> I don't like that ;-) Why aren't you using KABC::ContactGroup (preferably with
> the GID and not the uid).

I don't like my solution right now, but I also don't like using ContactGroups.

For single contacts, there's no backlinking from a contact to the
group without loading every group. For every data source that isn't
akonadi (telepathy and the skype one) that's a lot of extra loading of
things that aren't needed.

For fetching a model of everyone, I need to fetch every contact group
from every source then merge them into new fake contact groups. Then
presumably I should represent this as a tree in the model; which is a
complex tree as you have the same leaf items under multiple nodes.
Once I've done all this several clients are just going to flatten the
tree anyway which is a real waste.

Also ContactGroup brings in this concept of having email addresses in
groups that aren't references to contacts, I don't think I want to
support that - but maybe we do need to.

I think we need to have more of a play with integrating kpeople into
various clients and then we'll have a better idea of what API is
actually needed.

David
_______________________________________________
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/