KFileMetaInfo issue

[Peter Penz]

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.