--nextPart3928647.kOjdG2Aasv
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
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 xmlindex=
er
> > 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=
=20
these plugins instead of completely changing the KFMI interface and throwin=
g=20
away all the existing plugins.

> > I'm not convinced yet that KFMI using strigi as a backend is faster

Me neither.

=2D-=20
Nadeem Hasan (nhasan-at-nadmm.com)
GPG Fingerprint: 7141 0B1C 9CAF 624D 307F F8EF 6C0C 753E DD3A 0F53

--nextPart3928647.kOjdG2Aasv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFGoOybAx1Pt06D1MRAiMWAJ98/x4/AtEbVwsc1aYVa7e/gFvMFACeOCPM
kA3vgTMKHCnaKGXNGpZ5zzU=
=t0IR
-----END PGP SIGNATURE-----

--nextPart3928647.kOjdG2Aasv--