On Sat, Jan 30, 2010 at 3:03 PM, Jacob Rief <jacob.r...@gmail.com> wrote:

> > Please just don't add anything new.  If you are unhappy with what
> > ZeroCopy{Input,Output}Stream provide, you can always just create your own
> > stream framework to use.
> Well, I have to live with that decision. Maybe in the future some
> other people have similar use cases. Maybe in version 3?

I don't think this is that bad.  The ZeroCopyInputStream interface was
really designed to be an adaptor for using other streaming frameworks with
ProtocolBuffers.  It's not meant to be a streaming framework in itself --
that would be outside the scope of the library.  So, I'd rather keep the
interface as minimal as possible, providing only what is strictly necessary
for protocol buffers to operate.  I don't think Seek() or Reset() are
strictly necessary, and since it's not clear to me that either one is
necessarily "correct", I'd just rather not get into it.

> Just for curiosity, the protobuf code is really easy to read and to
> understand. The only thing is disliked is the mapping of class names
> to filenames. Is all the code inside Google written that clearly?

Thanks!  I don't know if I can give an unbiased answer to this question,
since I wrote most of the proto2 code, so of course to *me* it is the
clearest code in all of Google.  ;)  I think in general the code here tends
to be pretty high-quality due to our policy of reviewing every change
pre-checkin.  However, there is certainly some ugly code, mostly code which
evolved slowly over time with many different authors.

If you want to find out for yourself, we're hiring!  :)

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 

Reply via email to