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, 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
