jstreams and strigi for KFileMetaInfo

[Nadeem Hasan]

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 
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
-------------- 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/20060927/5cec76ca/attachment.sig>