kfilemetainfo using strigi

[Jos van den Oever]

2007/1/12, David Faure <faure at kde.org>:
> 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
Yes, a Strigi analyzer could work like that to call the current KFilePlugins.
Is there only one KFilePlugin per mimetype at the moment?

Cheers,
Jos

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