I think it would be better to revert the interface switch and rather
introduce a BDataOutput -> BDataIO adapter. This would allow using
BDataIOs with ZlibDecompressor while keeping the more concise interface.
Well, I'll schedule the whole series of related commits for reversal, then.
Sorry, I thought I had replied to this already.
I'm unsure how the wrapper can be done in a safe way, as you can't (by design)
assume it's possible to use a BDataIO for atomic writes. What would the wrapper
do if it can only write part of the data to the underlying BDataIO? should it
block until the remaining part can be written? Should it return an error, and
risk getting the following Write calls out of sync?
I don't see how it's possible to handle this in a better way using a wrapper.
It would only be masquerading incomplete writes as errors, leaving the caller
with no idea of how much data has actually been written. While this is probably
not a problem with the way BDataOuput is used in the package kit (it already
worked, after all), it can cause issues when used with other types of I/Os,
such as the DynamicBuffer currently in use in the Http code (this could go out
of memory when trying to write, but that's recoverable, once the consumer has
read enough data out of the buffer, the freed memory can be used again).
