[Kde-pim] Updating persistent search

[Christian Mollekopf]

On Thursday 19 December 2013 20.28:11 Daniel Vrátil wrote:
> On Monday 16 of December 2013 09:39:56 you wrote:


> > * If the search is configured to update itself, new item appear in the
> > result set as the necessary parts are indexed
> > 
> > The auto-updating queries are a nice feature, and with the local indexing
> > the server can test only the modified/new items to implement this while
> > not
> > becoming a complete performance hog. So IMO that would be pretty cool, but
> > doesn't have to be part of the first iteration.
> > In any case it probably makes sense to allow the application to control
> > what it wants (snapshot or auto-updating).
> > 
> > Since Akonadi is content agnostics you shouldn't care about which parts
> > are
> > locally available, but just evaluate what's there.
> 
> This however creates the weird behavior of emails, that don't have body
> cached in Akonadi suddenly appear in the search folder when you open them
> in KMail (i.e. when body is fetched from IMAP and indexed). This is the
> "incomplete results" I'm trying the avoid - the email matches the search
> criteria since the very beginning, but we are unable to detect it until
> some event occurs (like user opening the email).
> 

Well, I'm arguing that you shouldn't try to avoid that situation. At least not 
in the server. It might make sense in the local search agent, but it's not an 
assumption that is generally applicable I think. I.e. with online IMAP and 
IMAP server-side search you'd explicitly want to support that.

I'm also not sure that the "incomplete results" case is worth the extra 
handling as it i.e. shouldn't appear very often with offline IMAP, and in some 
cases you even want this explicitly (e.g. if you edit an event, and it matches 
the search query, you'd want that item to be added to the search results).

If you think it is worth handling, IMO a "snapshot" option that can be 
controlled from the client would handle this quite well, and avoid the 
workarounds in the search backend or even the server.

> > IMO it should be up to the agent or application to decide such things.
> 
> Yes, but we probably need to provide some infrastructure for this on the
> server.
> 

Indeed.

> > For instance, the whole
> > header vs. body discussion doesn't really make sense for calendar items as
> > all information only becomes available with the body.
> 
> Yes, this discussion is mostly about emails.
> 

Ok. I just want to make sure that the implemented system is generally 
applicable and not too specific for the email usecase (or the even more specific 
online imap with local indexing usecase).

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/