Making KFileMetaData a framework

[Vishesh Handa]

On Wednesday, August 06, 2014 04:09:19 PM Milian Wolff wrote:
> > 
> > Hmm, how would we do async? I thought people could just run it in another
> > thread / process if they want. The only thing I can think of changing is
> > that the plugins return the result later via a signal instead of doing all
> > the work in one function.
> 
> This would be good since it makes it trivial to use it then in a background 
> Thread - essentially you'd put a worker object into some thread/task which
> then emits a signal with the data when its ready. This could be the Manager
> (which then automatically finds the correct extractor for the given
> mimetype), or a certain Extractor, if you know which one should be used.

It might just be easier to make the manager return a QRunnable with all the 
extractors for that mimetype ready to run. And then you run them in a thread 
loop.

> 
> Though note that the above does not mean that a call to extract would be 
> async. It would still be sync. But you could use QFile and its readyRead 
> signals internally to process stuff asynchronously and then emit the data
> once  the end of the file is reached. If the signals are there (see above)
> this could be done without changing the API and thus could be done later.

With Qt we have QFile and readReady signals so this can be done. But a lot of 
the extractors use third party libraries which are quite often synchronous.

> > > What about the thread safety? At a glance I would say
> > > ExtractorPluginManager is not
> 
> This should be investigated. Note that it would be fine to load the plugins
> in  the ctor (which by definition is never thread safe). Just the usage
> later to match a given data set/file against the extractors and to get some
> result out of that should be made thread safe.
> 
> Bye

-- 
Vishesh Handa