On 11/26/2013 01:25 PM, Adrien Destugues wrote:
I'm adding gzip compression support to BHttprequest. I noticed we have ZlibCompressor and ZlibDecompressor classes in the package kit, which look like they would fit the job nicely. However, these use a BDataOuptut class to store their data. This looks like a write-only, package-kit private, version of BDataIO. Would it be ok to move these classes to the shared kit (or elsewhere) and make them use BDataIO instead? This would allow easier integration with other parts of the system, allowing to write the result in a BNetBuffer or a BSocket, in my case. What's the use for the BDataOutput class? Did I miss something that makes BDataIO unsuitable?
Maybe I've just done too much Java, but using a BDataIO where a unidirectional interface is required seems weird.
Anyway, the original reason for ZlibDecompressor not using BDataIO is that it is used in packagefs (i.e. in the kernel and the boot loader). Given that in the meantime (with the introduction of the package kit) BDataOutput has become quasi public API, I guess its status isn't much different from BDatIO's now. So pulling the latter into the kernel would be OK, I guess (BPositionIO and friends should be put in separate source files, though).
The use of the ZlibCompressor/ZlibDecompressor classes should be relatively isolated to the code reading/writing package and repository files. In fact when grepping for the classes only the static ZlibCompressor::CompressSingleBuffer() and ZlibDecompressor::DecompressSingleBuffer() methods show up at all, except for in the v1 package format code which is no longer needed (though removing it requires some adjustments in packagefs and the command line tools).
If you put the Zlib* classes to shared use, please remove the <zlib.h> dependency from their headers.
CU, Ingo
