They say on their website: "When evaluating new features, we look for additions that are very widely useful or very simple". What I'm suggesting here is both very useful (speeding up serialization and eliminating memory duplication) and very simple (simple additions to the encoding, no need to change the language). So far, no response from the Google guys...
On Monday, March 28, 2016 at 10:24:17 AM UTC-7, Peter Hultqvist wrote: > > This exact suggestion has been up for discussion long time ago(years?, > before proto2?) > > When it comes to taking suggestions I'm only a 3rd party implementer but > my understanding is that the design process of protocol buffers and its > goals are internal to Google and they usually publish new versions of their > code implementing new features before you can read about them in the > documents. > On Mar 27, 2016 5:31 AM, "Yoav H" <[email protected] <javascript:>> > wrote: > >> Any comment on this? >> Will you consider this for proto3? >> >> On Wednesday, March 23, 2016 at 11:50:36 AM UTC-7, Yoav H wrote: >>> >>> Hi, >>> >>> I have a suggestion fr improving the protobuf encoding. >>> Is proto3 final? >>> >>> I like the simplicity of the encoding of protobuf. >>> But I think it has one issue with serialization, using streams. >>> The problem is with length delimited fields and the fact that they >>> require knowing the length ahead of time. >>> If we have a very long string, we need to encode the entire string >>> before we know its length, so we basically duplicate the data in memory. >>> Same is true for embedded messages, where we need to encode the entire >>> embedded message before we can append it to the stream. >>> >>> I think there is a simple solution for both issues. >>> >>> For strings and byte arrays, a simple solution is to use "chunked >>> encoding". >>> Which means that the byte array is split into chunks and every chunk >>> starts with the chunk length. End of array is indicated by length zero. >>> >>> For embedded messages, the solution is to have an "start embedding" tag >>> and an "end embedding tag". >>> Everything in between is the embedded message. >>> >>> By adding these two new features, serialization can be fully streamable >>> and there is no need to pre-serialize big chunks in memory before writing >>> them to the stream. >>> >>> Hope you'll find this suggestion useful and incorporate it into the >>> protocol. >>> >>> Thanks, >>> Yoav. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Protocol Buffers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/protobuf. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
