Let's deal with the first case.  I can reverse the access placement and make Deflator pub with its fields priv.

------

Alex, first thank you for reviewing the code.  I apologize if I sound a bit blunt in the next few paragraphs.

Perhaps I didn't make myself clear.  Reader and Writer does not work for a good number of use cases at the DEFLATE level.  It's not that  the caller reads only 4 bytes and the rest of the decompressed data are cached in internal buffer.  It is that the decompression process does not know when the end of the compressed data is and will read extra data than needed beyond the compressed data.  Those extra data are not part of the DEFLATE data.  They belong to the next part of the higher level data stream protocol.  A DeflateReader has no good way to return those extra data it has consumed.

Here's an example.  The gzip data format has several parts.  Roughly, it has three sections: the gzip-related data section in front, the DEFLATE data section, and the gzip-related end section again.  The gzip process takes care of the beginning gzip-related data.  The deflate process only kicks in at the start of the DEFLATE data section.  However, gzip does not keep the length of the DEFLATE data section (because it wants to work in streaming mode with no seeking needed), so the deflate process does not know when the DEFLATE data section ends.  It can only decode the compressed data until reaching an internal encoded EOF symbol.  Any unused extra data are returned to the caller since those extra data are not part of the DEFLATE data.  In the gzip case, those extra data are the gzip's ending section.  The gzip process would come in again to decode those according to the gzip's spec.  As you can see a DeflateReader simply doesn't work in this case since a Reader can only return the decompressed data, not the extra data before or after.

The DeflateReader approach pretty much does not work in anything related to embedding a DEFLATE data segment in a streaming data, like in the network streaming case.

A DeflateReader only works if the caller knows exactly where the DEFLATE data ends and pass that much data to it, or in the degenerate case of feeding the deflate process one byte at a time, which would have awful performance.

The buffer approach handles all the different use cases, with reasonable performance.  Also the deflate module is for developers who write other higher level compression libraries, like gzip or zip.  It is not a general purpose library.  For general purpose compression, the developers should use the gzip module or other higher level compression library, that have Reader/Writer support.

The buffer approach API in the deflate module is absolutely non-negotiable.  Without it there would not be a working API.