[Kde-pim] Review Request 112362: Don't send ItemSearchJob queries through Akonadi

[Kevin Krammer]

> On Aug. 30, 2013, 7:45 a.m., Volker Krause wrote:
> > Good idea. However, I don't think it solves the actual problem (yet). ItemSearchJob is still an Akonadi::Job, and those are sequentially scheduled by Akonadi::Session. So, you'd still "block" the session while waiting for the results. This probably can be solved by making the job scheduler in Session aware of jobs that don't communicate with the Akonadi server.
> > 
> > Regarding the query language support other than SPARQL, the possible use-case here would be searching on IMAP or LDAP servers via the search interface of resources.
> 
> Christian Mollekopf wrote:
>     IMO the LDAP, IMAP search usecases are very important ones that I'd want to build upon in the future. I see nothing speaking against a shortcut for nepomuk queries though.
>     
>     Since searching resource backends will likely require specifying which resource to search we can either go with nepomuk by default for the search job and using a special constructor for resource search jobs, or we just do as you suggest and make the ItemSearchJob a nepomuk-only search, and create a ServerSideSearchJob when required. I think the latter option is better as the two probably don't have to much in common.
>     
>     So +1 for the idea, but please leave the rest of the server side infrastructure in place.

Having a different job for server side search sounds a bit problematic, a client would either have to do both jobs or somehow check first if there are resources that can do server side search.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112362/#review38913
-----------------------------------------------------------


On Aug. 29, 2013, 3:50 p.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112362/
> -----------------------------------------------------------
> 
> (Updated Aug. 29, 2013, 3:50 p.m.)
> 
> 
> Review request for KDEPIM-Libraries.
> 
> 
> Description
> -------
> 
> Instead of waiting for Akonadi to talk to Nepomuk and sending us matching items, we query Nepomuk from the ItemSearchJob and then use ItemFetchJob to fetch matching items from Akonadi.
> 
> This prevents blocking Akonadi session in case virtuoso goes nuts and does not respond to queries.
> 
> The only disadvantage of this approach is that we are losing support for anything else but SPARQL and Nepomuk, but we don't use anything else in KDE, so I don't know whether it's really a problem?
> 
> 
> Diffs
> -----
> 
>   akonadi/itemsearchjob.h 87d34b5 
>   akonadi/itemsearchjob.cpp 175c76e 
> 
> Diff: http://git.reviewboard.kde.org/r/112362/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

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