[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: jstreams and strigi for KFileMetaInfo
From: Nadeem Hasan <nhasan () nadmm ! com>
Date: 2006-09-27 13:59:02
Message-ID: 200609270959.14964.nhasan () nadmm ! com
[Download RAW message or body]
On Wednesday 27 September 2006 09:40, Jos van den Oever wrote:
> 2006/9/27, Carsten Pfeiffer <carpdjih@mailbox.tu-berlin.de>:
> If the user does not have strigi or the directory is not indexed, then
> the program xmlindexer would be run which would to the same thing KFMI
> normally does: get the metadata. This would be just as fast or slow as
> the current implementation. The status of strigi (available or not)
> could be cached and determining if a certain file should be available
> is also not slow.
This involves spawning a new process and would be slow compared to loading a
KFMI plugin.
> > So if we want to optimize strigi, we should have a look at what's
> > actually slow in KFMI and perhaps offer a lower level API that xmlindexer
> > could use.
I fully agree with this approach.
> The problem we're talking about is not mainly a problem for strigi. It
> can just use the current KFMI (although i dont recommend it because
> there are buggy plugins in there).
Which plugins do you think are buggy? It is not a big deal to fix/optimize
these plugins instead of completely changing the KFMI interface and throwing
away all the existing plugins.
> > I'm not convinced yet that KFMI using strigi as a backend is faster
Me neither.
--
Nadeem Hasan (nhasan-at-nadmm.com)
GPG Fingerprint: 7141 0B1C 9CAF 624D 307F F8EF 6C0C 753E DD3A 0F53
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic