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

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2004-06-09 18:50:25
Message-ID: 1086807024.30180.18.camel () localhost ! localdomain
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


El lun, 07-06-2004 a las 18:11, Gustavo Sverzut Barbieri escribió:

> > Creating the index is the problem. A backend process should be constantly
> > running at a low priority. Initially, it indexes all the files. Then, it
> > begins to index files as they change. It always keep a fresh index of the
> > most important files, and gets around to less important files when it has
> > the time.
> 
> That doesn't work.
> 	- a process accessing the disk everytime will screw up with OS disc caching.

On the contrary.  An indexing daemon which automatically indexes cached
files would work much faster since the worked-on file is, with 99%
probability, already in the disk cache.

Plus, new functionality certainly needs to have resources allocated.  As
this is free software, you can always turn it off, but I'm certain most
users would welcome such an advance, even if it screws which disk
caching, which, as I already laid out before, it won't.

> 	- IMHO, one may want to find the last file he/she accessed/saved/created 
> other than anything else. So these will be the most important... and probably 
> will not be indexed.

who said so?  That's the exact point of an index which would update
itself when files are modified (perhaps one or two seconds later).

One or two seconds for updates doesn't seem that slow to me.

> ...> the database part of the tool. The requirements for the index cache are
> > very different than what PostgreSQL provides. I do believe that we can
> > steal a lot of ideas from the database community on how to search vast
> > indexes efficiently. Perhaps early implementations will rely on a database,
> > but that should be temporary.
> 
> I also don't think so.

Well, Jonathan, you might not think so, but it's the fastest route to a
rich metadata desktop system.  You need an index (for which you need a
database), you need a file alteration monitor, and you also need a
system which performs live queries to the index.  It's also exactly what
Microsoft is doing with Longhorn.  Only I'd like to see that the
metadata is stored directly with the file as EAs, and indexed, while
Microsoft is putting metadata in the Yukon database (a direction which
will probably make most backup tools obsolete).


-- 
	Manuel Amador
	Jefe de I+D                         +593 (9) 847-7372
	Amauta                     http://www.amautacorp.com/
	GNU Privacy Guard key ID: 0xC1033CAD at keyserver.net

["signature.asc" (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


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