[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Full Text Indexing for kmail
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2005-03-28 10:46:59
Message-ID: 200503281247.09263 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 28 March 2005 11:35, Luís Pedro Coelho wrote:
> Thanks Ingo for your answers, but I have a couple more.
>
> I now have only one interface working: The search bar which in HEAD
> filters only on headers, filters on contents too with my patch. I
> think one needs to at least plug the search dialog but I haven't
> quite figured out yet.

It's debatable whether the search bar should do a full text search. The 
point for the search bar is mostly used to quickly find messages. I 
mostly use it for finding messages which were sent by a certain person 
or which have a certain subject. The latter is actually problematic 
because one might not know which subject someone chose for his message 
but one might know a few words which occurred in his message. So in 
this case a full text search is better than just a search of the 
subject. In the other case (searching for messages sent by a certain 
person) a full text search will result in undesired matches, but I 
guess in pratice the number of false positives won't be too large.

In any case, the quick search should be quick. So doing a full text 
search is only okay if it takes less than 1 second on a large folder.

> I see that searching in KMail seems to be around KMSearch,
> KMSearchRule and KMSearchPattern, KMFolderSearch but I haven't quite
> figured it out yet. Can anyone give me a 1000-mile high view of how
> these fit together?

A little bit information can be found in the DESIGN file (in the section 
about filters). A search is basically a filter without any filter 
actions. I quote the relevant bits of information:

"The search pattern is a QPtrList of search rules (kmsearchpattern.h) 
and a boolean operator that defines their relation (and/or).

A search rule consists of a field-QString, a "function"-enum and a
"contents" or "value" QString. The first gives the header (or
pseudoheader) to match against, the second says how to match (equals,
consists, is less than,...) and the third holds the pattern to match
against.
  Currently, there are two types of search rules, whcih are mixed
together into a single class: String-valued and int-valued. The latter
is a hack to enable <size> and <age in days> pseudo-header matching."

KMSearch is the class which performs a search.

KMFolderSearch represents a search folder (i.e. a dynamically updated 
virtual folder which contains the result of a search).

> Also, in KMSearchRule, there is an enum Function with a series of
> functions and I wonder what function my index fulfils. It looks like
> FuncContains, but it probably is something new, like
> FuncKeywordContains since it searches for "term" or "term*" while
> contains suggests "*term*". Should I start by defining this new
> function?

I think using FuncContains is okay. Note that the full text search 
corresponds to the search rule "<body> contains ...". Of course, it can 
also be used for "<message> contains ..." in order to find matching 
messages more quickly, but if the full text search doesn't return a 
message we still have to search the entire message the old slow way.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic