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

On Wednesday 27 September 2006 15:40, Jos van den Oever wrote:

> 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)

Except that it's a separate process with IPC and marshalling involved. Unle=
ss=20
xmlindexer would be available as an API. But then it would be close to KFMI=
=20
again, I suppose.

> 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). The point is retrieving the

I we're talking about bugs, the let's fix them! Or does strigi have=20
alternative, bug-free implementations for those plugins?=20

I'm all for having one extensible thing that extracts meta-data from files,=
=20
and doing it right. And that's what KFMI intends to do. If it fails to do=20
that, I'd like to hear about it.

> > I'm not convinced yet that KFMI using strigi as a backend is faster
> > (contacting the strigi daemon, checking if the file is indexed, checking
> > if the index is up to date, possibly indexing it, then sending the
> > metadata back to the KFMI (as XML?) and converting it into KFMI
> > datastructures).
>
> Checking if the index is up to date is easy: Strigi has the mtime of
> each entry. This can be compared to the mtime on the filesystem. If
> the data is not indexed or outdated, it should not be automatically
> reindexed. In such a case, KFMI would call xmlindexer directly and use
> the results from that.
>
> I am also not sure it would be faster to retrieve the data in this
> way. That's why I said "would be (should be)".

Then I don't see any advantage anymore!? Why should KFMI use strigi as a=20
backend then, if it's not going to be faster? The only possible benefit I s=
ee=20
would be strigi's indexing becoming faster by not using KFMI anymore, but=20
what are actually the bottlenecks with that?

Too bad I wasn't at the strigi BoF :-(

Cheers,
Carsten

--nextPart37417739.lktihaDFMq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iQEVAwUARRqGEKWgYMJuwmZtAQLbcggAjSyNyPIWNMonc8NgxU9cSHsDveFbqreX
O40DbKUr4HioSj0tEa24LY29+5yQxG4LhMb+HWEUTemldI0WzMTp5uNmzrkDqqyr
5dZZwm7r1JH3wDKCSC7V4RBVQHxUJWfTLnLXi7oBdF5F0+knjQkxWzSN6NJDnRh8
6g18zOaR7apK4LB3FUPZnwJ8X8xnEP3Q/pxBM96AuZ62wWeoqNApnK9rKdgZwwCb
hKnDjWmlgSlbGoAlC3wfU4YaAn46nR3mrQ8gCnDZtjXpdTgpq9oDUeX3vJBJoror
9qdauE5M0DMY+fuFpvUUR2T8cCoQGSsI4qUl6gui1ikaRgOVgVDSYw==
=Rj8A
-----END PGP SIGNATURE-----

--nextPart37417739.lktihaDFMq--