[Kde-pim] Releasing libkpeople 0.2.0
Christian Mollekopf
chrigi_1 at fastmail.fm
Mon Feb 10 08:45:11 GMT 2014
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/
More information about the kde-pim
mailing list