jstreams and strigi for KFileMetaInfo
carpdjih at mailbox.tu-berlin.de
Wed Sep 27 15:09:19 BST 2006
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. Unless
xmlindexer would be available as an API. But then it would be close to KFMI
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
alternative, bug-free implementations for those plugins?
I'm all for having one extensible thing that extracts meta-data from files,
and doing it right. And that's what KFMI intends to do. If it fails to do
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
backend then, if it's not going to be faster? The only possible benefit I see
would be strigi's indexing becoming faster by not using KFMI anymore, but
what are actually the bottlenecks with that?
Too bad I wasn't at the strigi BoF :-(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 447 bytes
Desc: not available
More information about the kde-core-devel