jstreams and strigi for KFileMetaInfo

[Carsten Pfeiffer]

On Tuesday 26 September 2006 18:45, Jos van den Oever wrote:

Hiya,

> Strigi has  an executable called 'xmlindexer' which output metadata
> about files as xml. KFileMetaInfo would normally query strigi for the
> metadata of a file. If the particular file is not indexed because it's
> very new, not in an indexed directory or because the strigidaemon is
> not running, then KFileMetaInfo would call 'xmlindexer' on the (list
> of) files.
>
> Doing this would have a few advantages:
>
> - indexing of metadata would be more efficient because strigi would
> not need to call KFileMetaInfo
> - KFileMetaInfo would be indexed and searchable
> - retrieving KFileMetaInfo would be (should be) more efficient,
> because the data is read from the database and is not generated on the
> fly
>
> So my proposal is to port KFileMetaInfo to xmlindexer and
> strigidaemon. The call to strigidaemon would go through the kde strigi
> calling class (in development).

so all the KFileMetaInfo plugins need to be to ported xmlindexer, then? I 
suppose it offers a similar API?

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.

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.

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

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/98fb8ab3/attachment.sig>