jstreams and strigi for KFileMetaInfo
nhasan at nadmm.com
Wed Sep 27 14:59:02 BST 2006
On Wednesday 27 September 2006 09:40, Jos van den Oever wrote:
> 2006/9/27, Carsten Pfeiffer <carpdjih at 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
> > 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
Nadeem Hasan (nhasan-at-nadmm.com)
GPG Fingerprint: 7141 0B1C 9CAF 624D 307F F8EF 6C0C 753E DD3A 0F53
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel