18 février 2014 14:58 "Stephan Aßmus" <superstippi@xxxxxx> a écrit:
I completely fail to see what the problem is.
As far as I understand, you want to use a class which implements BDataOutput in
a context where you
need a BDataIO. As Ingo pointed out, instead of changing all the places where
BDataOutput was
previously used, you could have simply written a BDataIO which wraps a
BDataOutput. The fact that
BDataIO can in theory return less bytes from Read() then requested, is
completely irrelevant in
this context, since when the underlying BDataOutput (the deflate output) only
returns all or
nothing, then that's what happens in your wrapper. It simply has the behavior
of always returning
the requested number of bytes. Why would that be any sort of problem?
The "problem" is the other way around; a BDataOutput that wraps a BDataIO. I'm
concerned with the case where the loop (in the code you provide below) iterates at least
once, writing some bytes, and then fails. With the current BDataOutput API, all it can do
is return the error code, leaving the caller with no information about how much data was
actually written (that's the whole point of using that different class - the caller
doesn't want to handle that).
The case where a write error is only temporary (in my case, a buffer that is full, but
can be emptied and reused later) is a bit more tricky to handle. I was trying to handle
that in the ZlibDecompressor, to resume writing exactly where it stopped, but now I see
it can be done in the adapter, by having ZlibDecompressor "replay" the failed
write, and the adapter ignore the bytes it has already written (it must keep track of
this internally, by remembering how many bytes were wrote during the last call). This
makes the adapter only slightly more complicated, and it's a good solution.
