jstreams and strigi for KFileMetaInfo

[Jos van den Oever]

2006/9/27, Carsten Pfeiffer <carpdjih at mailbox.tu-berlin.de>:
> Then strigi indexing might indeed become faster. However, KFMI would become
> slower for everyone not using strigi. E.g. most of the laptops have slow IDE
> drives where I wouldn't want to have an indexer running. I do use
> slocate/updatedb, but I hate it when it's running, because I basically cannot
> do anything else because of the I/O.
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.

> 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.
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
metadata could be gotten from Strigi, if Strigi is available and be
generated by xmlindexer if that data is not in an available cache.

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