On Jun 1, 9:37 am, Kenton Varda <ken...@google.com> wrote:
> The official implementations do NOT accept multiple encodings, but it would
> theoretically be possible for them to do so.  This wasn't implemented mainly
> because code size bloat is a big problem and accepting multiple encodings
> would increase code size -- even users who don't even use [packed=true]
> would be affected, since they'd still need to generate code which accepts
> it.

I totally understand this concern.  On the other hand, I'm a bit
afraid of a precedent that options are part of the interoperability
contract -- that your options have to match for you to interoperate
properly.  Most options are things that are more like preferences.
They are things that one application might *want* to do differently
than another application, even though the two applications are
interoperating.  Having some options that can vary and some options
that must not vary sounds like a recipe for problems.

To me the right answer is to draw a line in the sand and say "options
can't break interoperability of serialization/deserialization."


> That said, I'm up for reconsidering this decision.
> On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman <jhaber...@gmail.com>wrote:
> > I was reading the documentation about packed encoding [0] (haven't dug
> > into the code), and was wondering if parsers are expected to be able
> > to read packed encoding whether or not [packed=true] is specified.
> > Unlike any other option (AFAIK), [packed=true] actually changes the
> > bytes that encoders will output.  It seems like decoders must be
> > prepared to read either packed or non-packed encoding of repeated
> > fields.  Is this the case?  The alternative (that [packed=true] is not
> > interoperable with [packed=false]) seems undesirable.
> > Josh
> > [0]
> >http://code.google.com/apis/protocolbuffers/docs/encoding.html#optional
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to