config option for KDirWatch method

[Aaron J. Seigo]

On Tuesday 21 August 2007, Dirk Mueller wrote:
> On Tuesday, 21. August 2007, Flavio Castelli wrote:
> > We watch recursively all indexed directories. In this way Strigi's index
> > will be up-to-date and user searches will be consistent (we won't return
> > deleted or no more valid contents nor we will omit a valid one).
>
> As I tried to express previously: thats an extremely stupid idea. strigi

only so long as it is implemented stupidly or you don't actually care about 
having a useful search system on your computer. i grant it will be tricky to 
get right and should not be used on all parts of the file system.

> should not interfer while my "svn update" touches 15000 files. it can do
> that when I`m away and do not care about my computer, but it shouldn`t do
> that while I`m sitting in front of the machine and wait for something to
> finish.

but it should know that something needs to be updated and schedule that. the 
reality check here is that most people don't touch 15k files at once. *most* 
people save a file here or there, open a file here or there, get 15 or 20 
emails, chat with a couple of friends (creating log histories).

things like chat logs and probably even emails should not be handled 
via "watch the file system for changes". best would be that index updates are 
fed to the storage system by the application that is processing the data: 
it's already in memory and being processed, so it's the perfect time to also 
index it.

pretty much everything else can and should be indexed when (or shortly after 
being) changed, with the ability to exclude areas on disk for those crazy 
people like us who svn up and change a few thousand files all at once. in a 
beautiful world, we'd get scm projects to add optional on-the-fly indexing as 
well.

indexing should also be throttled when operating on battery power.

as i said, not trivial to get perfect, but doable.

> I`ve tried to talk about this with Jos already and it seems we have
> conflicting goals here.

if by "we" you mean "us as developers and the rest of the world as users" i'd 
agree.

> However, from experience with beagle I know that 
> the number 1 complain isn`t that it doesn`t find not-yet indexed documents,
> but that it drains system ressources like crazy.

i think those two things are linked. the more out of date a system is, the 
less useful it is. if i can't find items that are new or updated in the last 
N hours, then i have to fall back to other means (e.g. manual file system 
searching in konqi/dolphin) which makes the search system less useful. less 
useful == worth less, which in turn means that every bit of resources that 
search system uses is more and more annoying.

alternatively, if that search system is "always" accurate and has what i need 
at my fingertips it becomes insanely more useful, and i'm much more forgiving 
towards its resource usage.

usefulness == willingness to forgive.

that said, this is all a bit moot because kernel devs, such as those that work 
on the linux OS, can't seem to figure out how to do these things efficiently. 
either it's a touch problem in the kernel level, they don't care about the 
needs of the desktop or they are just plain stupid when it comes to solving 
these kinds of problems.

but let's try not to discourage people from working towards optimum solutions 
by calling said optimum solution "extremely stupid" just because it's not 
easy to get right. by that metric, much of kde is extremely stupid.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070821/47ce67cc/attachment.sig>