On Friday 06 November 2015 08:47:34 Luiz Romário Santana Rios wrote:
> 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.
Ah, I see.
> > 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.
Blocking while uncompressing is OK (fast CPU operation),
blocking while waiting for network packets is not (could take 30 minutes).
But now I see, you do an async download first, so no issue there.
> Then we could use a temp file in the KZip implementation and this
> approach for KTar?
I wouldn't want this for the case of random access devices, like
files on disk (it would be pointless to copy from a local file to a tempfile).
But yes I'm not opposed to code that would use a temp file for
cases of non-sequential devices being used as input.
Aleix suggested QBuffer, but archives can be *huge*, so this might
eat all available memory. This is the reason why KTar uses a temp file
for the compressed-tar case.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
