Failure while executing KTar::open while using KCompressionDevice as the device

[David Faure]

On Saturday 21 November 2015 15:50:31 Luiz Romário Santana Rios wrote:
> , or make the waitFor* calls and warn the user
> that passing a QIODevice which is not yet fully ready to
> KCompressionDevice might make KTar::open() block.

That would work I guess. In a unittest or a non-gui tool
or a secondary thread, blocking might be fine.
I assume by "warn" you mean in the documentation, not at runtime.

> A suggestion I made in the IRC channel was this: add a constructor
> argument -- or a flag -- called "Buffered" or "Cached"; if enabled,
> the data stream from the QIODevice would be buffered or copied to a
> tempfile, then that buffer or file would be extracted; if disabled,
> the QIODevice would be accessed directly for its data; then, make it
> enabled by default.

This all sounds quite complex compared to just waitFor*, no?
The buffering is already done by QNetworkReply, I don't see much point
in adding another buffer on top.

> Another thing: KCompressionDevice only seems to support tar files
> (.gz, .bz2, and .xz), so why would KZip be an issue anyway?

KZip uses KCompressionDevice internally, to decode zlib-encoded data.
But I lost context of why we were talking about this.
It's indeed different because it's not "KZip on top of a compressed QIODevice",
that wouldn't make sense indeed.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5