[Kde-pim] Releasing libkpeople 0.2.0

[Christian Mollekopf]

On Sunday 09 February 2014 22.30:11 David Edmundson wrote:
> We are about to release a 0.2.0 release of libkpeople. As you can
> imagine after the nepomuk situation we had to rewrite a lot.
> 
> I don't think we are completely ABI stable there are a few quite a few
> things I want to change, however it is at a good point that I would
> like some reviews and feedback.
> 

Hey,

Great seeing this taking shape =)

Currently I'm very busy porting the rest of kdepim to baloo, so the full 
review will have to wait a bit.

> 
> 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).

>  - Multiple refreshes
>    - Because we have lots of plugins loading asynchronously, they feed
> in their own contact data at various times. Each time we get new
> information, we update the model which is a lot of dataChanged()
> calls. The other option is to wait for everyone to load everything,
> but then I'm only as fast as the slowest datasource. Which also sucks.
> 

I'd just emit the dataChanged signal everytime. Worst-case the signals could 
be compressed.

>  - Searching:
>     - With Baloo, each app has to implement it's own search store. For
> Akonadi this is fine, we create a ContactsSearchJob then get the
> relevant IDs. We can then ask KPeople to fetch that item, which will
> then in turn that does an akonadi fetch job with a full payload on all
> relevant contacts to that person. Scarcely any slower than before.
>       However from a krunner POV we want to search all contacts from
> all sources - I won't have all this indexed. 

I think this means every
> contact source also needing to write a baloo search plugin. I don't
> know what we'll do here.
> 
I think so too.

Cheers,
Christian

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