2015-11-06 4:48 GMT-03:00 David Faure <fa...@kde.org>: > On Monday 02 November 2015 14:53:40 Luiz Romário Santana Rios wrote: >> >> I'm trying to decompress a XZ archive downloaded using >> QNetworkAccessManager, so, according to the documents, I have to pass >> the QNetworkReply pointer to a KCompressionDevice > > I don't think this can work at all. > (and yes I've seen your review request, but while it fixes the file:/// case, > are you sure > it fixes the network case as well?)
Since I wait for the QNAM::finished() signal before doing anything with the QNetworkReply, it probably does, but maybe not for, say, a QTcpSocket. That case would need the waitFor*() calls, indeed. > > Here's the issue: > while QIODevice is indeed one single API, there are two ways to use it: > push and pull. Or in other words, async and sync. > > The push / async use case is the one used with sockets (including > QNetworkReply). > You wait for data to be available and only then read it. Waiting can be done > blocking > or with the event loop (signal/slot connection). > > The pull / sync use case is code that assumes there's always data available, > as is the case with QFile, QBuffer etc. This is what KCompressionDevice, > KTar, KZip > etc. all assume. > > So the reason it breaks (apart from the issue of seeking) is that when KTar > (or KCompressionDevice) wants to read more data, it might not be available, > and the read fails. You could add waitFor* calls, but that would make the > whole > thing blocking - very bad for the main thread of a GUI program. It already blocks, even in the KTar archive("file.tar.gz") case. > > So instead I do recommend using KIO (or QNAM) to make an async download > (keeping the GUI reactive, allowing for a progress bar if desired...), and > only > once the stuff is in a tempfile, you can create a KArchive on top. > > KTar is somewhat linear so your patch + waitFor* might make it work but > KZip requires a lot more going back and forth in the file, so this will never > work > without a temp file. Then we could use a temp file in the KZip implementation and this approach for KTar? > > In the special case of tar+compression in readonly mode, KTar already creates > a temp file, for the uncompressed tar, for faster seeking. This might also be > why you make it work in this very case, but that doesn't help for the other > cases > (not tar, or not compressed) > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > -- Luiz Romário Santana Rios _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel