KFileMetaInfo issue

[Sebastian Trüg]

There are two solutions when using Strigi:
1. Hack Strigi to support a fastest flag -> a lot of work I think. Probably
   not worth it, seeing that there are still analyzers to be ported.
2. Do it in KFileMetaData by restricting the number of bytes that Strigi can 
   read. I did not test this and have no idea if it will actually work.

The only problem I see with using Nepomuk is that Nepomuk is still optional in 
KDE and that this will only get us metadata for actually indexed files.
I personally have no problem with this (obviously) but there might be other 
voices...

In any case the Nepomuk workshop will be a good opportunity to work on these 
issues.

Cheers,
Sebastian

On Wednesday 10 June 2009 13:34:07 Peter Penz wrote:
> Hello,
>
> Until KDE 3.5 using KFileMetaInfo with the "Fastest" flagged assured [1]
> that invoking the constructor does not block the caller for several
> seconds. In this case the caller of KFileMetaInfo accepted getting only the
> meta information that can be received without the need to parse the whole
> file.
>
> Since KDE 4.0 KFileMetaInfo uses Strigi to get the meta data and the
> "Fastest" flag is ignored. Now getting the meta information of a huge MP4,
> PDF or ZIP file can take several seconds (see e. g.
> https://bugs.kde.org/show_bug.cgi?id=179523).
>
> My basic question is how KFileMetaInfo is intended to be used when
> specifying the "Fastest" flag:
>
> (A) If the callers may use it synchronously (e. like done in
> KFileItem::getToolTipText()) IMO opinion it must be assured that the
> response time is "small" (< 1 second?).
>
> (B) If the callers may not rely on a small response time, then this should
> at least be mentioned in the API.
>
> KFileMetaInfo is used very often (http://lxr.kde.org/ident?i=KFileMetaInfo)
> and as far as I could see only synchronously...
>
> Dolphin for KDE 4.3 uses Nepomuk for the Information Panel to bypass this
> issue. Still the issue pops up again when turning on tooltips, as the
> tooltip text is received by KFileItem::getToolTipText() which uses
> KFileMetaInfo internally... :-(
>
> Any ideas how to proceed here? One thing that comes into my mind is that
> KFileMetaInfo might use Nepomuk to get the meta data instead of
> synchronously using Strigi.
>
> Best regards,
> Peter
>
> [1] "Assured" is probably not correct, but practically this was the case.