jstreams and strigi for KFileMetaInfo

[Carsten Pfeiffer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 447 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060927/27216aa9/attachment.sig>