Re: packed encoding question
In theory I completely agree with you. :) On Mon, Jun 1, 2009 at 9:55 AM, Joshua Haberman wrote: > > On Jun 1, 9:37 am, Kenton Varda 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." > Thoughts? > > Josh > > > That said, I'm up for reconsidering this decision. > > > > On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman >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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: packed encoding question
On Jun 1, 9:37 am, Kenton Varda 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." Thoughts? Josh > That said, I'm up for reconsidering this decision. > > On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: packed encoding question
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. That said, I'm up for reconsidering this decision. On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: packed encoding question
> and was wondering if parsers are expected to be able > to read packed encoding whether or not [packed=true] is specified. I wondered the same thing; I don't know about the *official* versions, but for my codebase I use the "Be strict in what you send, but generous in what you receive" approach. Hence my version (to be committed probably later today) allows, for suitable types, either as input (regardless of definition), but will only output the variant as defined in the schema. This is also the approach it takes re group/ length-prefixed sub-messages. Marc (protobuf-net) --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
