[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: jstreams and strigi for KFileMetaInfo
From: Carsten Pfeiffer <carpdjih () mailbox ! tu-berlin ! de>
Date: 2006-09-27 14:09:19
Message-ID: 200609271609.20106.carpdjih () mailbox ! tu-berlin ! de
[Download RAW message or body]
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 :-(
Cheers,
Carsten
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic