kfilemetainfo using strigi

[David Faure]

On Friday 12 January 2007 11:20, Jos van den Oever wrote:
> 2007/1/12, Sebastian Trüg <trueg at k3b.org>:
> > How about providing a compatibility wrapper strigi plugin that is able to load
> > KFilePlugins? This way all the old plugins could be reused until they have
> > been ported. Is that possible or do we get a problem with the streaming
> > issue?
> 
> This is a possibility, yes. This will only mean that files that are
> not readable through QFile will not work. This is the case now too, so
> there's no problem there.
> The hard bit is in how to change the API of KFileMetaInfo. Some things
> in there have to change:
>  - Interface must pass a QIODevice and not a QFile (easy change)
>  - We have to reconsider the role of the mimetype. In Strigi mimetype
> has no meaning. Each analyzer looks at the content of the file and
> determines from that what it can get out. In KFileMetaInfo, the
> combination mimetype + KFilePlugin instance determines the fields that
> could be available for a file. In Strigi you dont need the mimetype
> for that, but you do need to know if an analyzer can handle a specific
> file.

You just need an intermediate layer then.
KFileMetaInfoStrigiAdapter (or any shorter name) would be the strigi analyzer that
implements that strigi interface ("can you handle this file?") and the implementation
of that would 
1) determine the mimetype (KMimeType::findByPath)
2) find and load the KFilePlugin for it

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).