Making KFileMetaData a framework

[Kevin Ottens]

On Wednesday 06 August 2014 17:47:49 Milian Wolff wrote:
> > > 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.
> 
> Right, then imo just leave it as-is but still add some signals which make it
> simpler to use the code as a worker object in a thread. At least, that's my
> opinion. Not sure what Kevin has to say in that regard.

My opinion is that the threading shouldn't be forced on the client code. So I 
would say: signals for the API. If you reuse something third party which 
doesn't even allow for polling then the thread should probably be in the 
extractor.

In other words: hide the constraints from the third party libraries you are 
forced to use, don't leak them to your users.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140812/57ff902b/attachment.sig>