2015-11-25 18:53 GMT-03:00 David Faure <fa...@kde.org>: > 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.
Yes, that's what I meant; > >> 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. Of course. Although I'll still have to figure out how to open the KCompressionDevice without needing to seek forward -- see my reply to Aleix Pol. After that, I'll think about how to wait for the data. > >> 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. It was an answer to this: > 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. > > -- > 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
