[Kde-pim] Porting StdAddressBook to Akonadi does not work as Akonadi::ContactSearchJob returns no results

[Cristian Oneț]

În ziua de Vin 08 Feb 2013, la 09:40:21, Kevin Krammer a scris:
> Hi,
> 
> On Wednesday, 2013-02-06, Cristian Oneț wrote:
> > Hi,
> > 
> > I'm having problems replacing the deprecated StdAddressBook API with
> > the new Akonadi::ContactSearchJob API (in KMyMoney) as it's
> > recommended here [1]. The problem is that it does not work as expected
> > since the ContactSearchJob returns no results with Nepomuk disabled.
> > This dependency is not mentioned in the porting guides that I've read
> > so it's a bit frustrating since I had Nepomuk turned off due to the
> > often recurring 100% CPU usage issues.
> 
> At the time of writing I assumed that Nepomuk would always be running in a
> PIM setup due to many things depending on effective search.
> Since it is a living document you can of course update it when you've found
> an alternative solution that is accetable for your use case and document
> its assumptions as well.

I'm using PIM on a daily basis with Nepomuk off without noticing any lack of 
functionality (except the missing Kmail address autocompletion) so it was kind 
of a surprise to me to find out about this runtime dependency in the PIM API.
 
> > At this point I went on and enabled Nepomuk together with the email
> > indexer. I waited for the indexer to finish it's initial indexing.
> > Then ran the ContactSearchJob again. This time the search by email
> > query took about 1 minute of 100% CPU usage from Nepomuk (I have 45
> > contacts in my address book) but again without any results. Even tried
> > to run the 'Search contact by email' query from the Akonadi console
> > but all I've got on Akonadi's output was 'QStringList
> > Akonadi::NepomukSearch::search(const QString&) Calling blockingQuery()
> > failed! '.
> 
> No idea there.

I'll try to get some help on #nepomuk-kde for this.

> 
> > From there I've found out that in 4.10 KMail will be able to perform
> > the auto completion without Nepomuk [3]. I've tried a similar approach
> > which works as expected without any issues. The only thing that
> > bothers me is that you need to iterate over all contacts to find the
> > one that you are looking for (having the email of the KDE user
> > obtained with IdentityManager).
> 
> This is the runtime equivalent of what StdAddressBook did. You can
> potentially improve on that by only loading minimal contact payloads
> (ContactPart::Lookup, see akonadi/kabc/contactparts.h) while searching.
> 
> > Anyway for my 45 contacts this works as expected and a lot faster then the
> > whole Nepomuk indexing engine.
> 
> This is definitely strange. The whole point of using an index for search is
> to make it faster than simple linear search.
> Do you also get this speed difference when both approaches use the same data
> set? I.e. when you do not use mail indexing (and thus adding all address
> contained in emails).

I guess that if Nepomuk would work on my system the indexed approach would be 
faster but for now I think that I'll stick to the linear search approach 
because at least I know that it's working and it's performance is not critical 
from the application's POV (it's in a rarely used feature).

> 
> > I'm writing this mail because I've tried yesterday (without success)
> > on #akonadi to get some hints about what could be wrong with Nepomuk
> > on my setup. Maybe I could provide valuable information to fixing [2]
> > I just need to know where to look.
> 
> Maybe the wrong channel. I think Nepomuk people mostly hang out in #nepomuk-
> kde
> 

You're right, I didn't thought about that.

> > About searching trough the contacts in Akonadi without Nepomuk [3]. Is
> > it OK to use it in non-KDEPIM applications?
> 
> From the point of view of the Akonadi setup there is no difference between
> applications. It offers functionality and you use that in any way you see
> fit.
> 
> KDEPIM applications could be seen as a starting point for looking for usage
> patterns, however due to their age and complexity they are often not yet
> using Akonadi in the best possible way.
> 
> > Isn't there an easier way
> > to obtain the Akonadi:Item using the email address?
> 
> There are three options:
> - linear search: walking through all contacts, compare addresses
> (potentially only loading partial contacts, see above)
> 
> - loading all contacts and sorting by email, then doing local lookup
> 
> - using the search facility. naturally this one is expected to be the most
> efficient (delegating the lookup to a component specialized in search). No
> idea why that is not the case for your setup.
> 
> > Do you see some
> > performance issues in this approach?
> 
> Probably taking a bit more time than the StdAddressBook approach due to more
> round-trips, but on the other hand potentially needing less memory (not
> having to load all contacts in full) and being fully asynchronous.
> 
> > I would prefer this approach
> > since it works with Nepomuk disabled which is a possible scenario (the
> > user can do it from SystemSettings).
> 
> Detecting that is something we might need to have a common solution for.
> E.g. an application requiring lookup would just instanciate a checker and
> that checker would probe the system and display an application specific
> hint if some functionality is temporary unavailable until Nepomuk is
> enabled.
> 
> On the exmaple of KMail something like "KMail has detected that you have
> disabled contact search. Please enable if you want to use address completion
> or contact groups."
> 
> Of course assuming that whatever makes contact search so slow in your case
> can be fixed.

I'm sure it can.

> 
> If not we might consider a customs search service for most common PIM
> queries and have e.g. ContactSearchJob use that (or use it as a fallback).
> I.e. allow applications to always use the search job.

This would be nice. One other thing that would be nice is if ContactSearchJob 
would report an error if it could not perform the search due to a runtime 
error like Nepomuk being disabled or not running, or whatever.

-- 
Regards,

Cristian Oneț
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130209/8c7fbd08/attachment.sig>
-------------- next part --------------
_______________________________________________
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/