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

[Luiz Romário Santana Rios]

2015-11-25 18:53 GMT-03:00 David Faure <faure at 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, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>



-- 
Luiz Romário Santana Rios