Thanks for writing this code! I'm sure someone will find it useful.
That said, I'm wary of adding random stuff to the protobuf library. gzip
made sense because practically everyone has zlib, but lzlib is less
universal. Also, if we have lzip support built-in, should we also support
bzip, rar, etc.?
Also note that libprotobuf is already much larger (in terms of binary
footprint) than it should be, so making it bigger is a tricky proposition.
And finally, on a non-technical note, adding any code to the protobuf
distribution puts maintenance work on me, and I'm overloaded as it is.
Usually I recommend that people set up a googlecode project to host code
like this, but lzip_stream may be a bit small to warrant that. Maybe a
project whose goal is to provide protobuf adaptors for many different
compression formats? Or a project for hosting random protobuf-related
utility code in general?
On Tue, Dec 8, 2009 at 4:17 AM, Jacob Rief <jacob.r...@gmail.com> wrote:
> Hello Brian, hello Kenton, hello list,
> as an alternative to GzipInputStream and GzipOutputStream I have
> written a compression and an uncompression stream class which are
> stackable into Protocol Buffers streams. They are named
> LzipInputStream and LzipOutputStream and use the Lempel-Ziv-Markov
> chain algorithm, as implemented by LZIP
> An advantage for using Lzip instead of Gzip is, that Lzip supports
> multi member compression. So one can jump into the stream at any
> position, forward up to the next synchronization boundary and start
> reading from there.
> Using the default compression level, Lzip has a better compression
> ratio at the cost of being slower than Gzip, but when Lzip is used
> with a low compression level, speed and output size of Lzip are
> comparable to that of Gzip.
> I would like to donate these classes to the ProtoBuf software
> repository. They will be released under an OSS license, compatible to
> LZIP and Google's. Could someone please check them and tell me in what
> kind of repository I can publish them. In Google's license agreements
> there is a passage telling: "Neither the name of Google Inc. nor the
> names of its contributors may be used to endorse or promote products
> derived from this software without specific prior written permission."
> Since I have to use the name "google" in the C++ namespace of
> LzipIn/OutputStream, hereby I ask for permission to do so.
> Comments are appreciated,
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at