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.
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 protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
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...
|3||Start group||groups (deprecated)|
|4||End group||groups (deprecated)|
On Mon, Mar 28, 2016 at 10:53 PM, Yoav H <joe.dai...@gmail.com> wrote: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...Actually there are already a "start embedding" tag and a "end embedding" tag in protobuf:
3 Start group groups (deprecated) 4 End group groups (deprecated)They are deprecated though.You mentioned it will be a performance gain, but what we experienced in google says otherwise. For example, in a lot places we are only interested in a few fields and want to skip through all other fields (if we are building a proxy, or the field is simply an unknown field). The start group/end group tag pair forces the parser to decode every single field in the a whole group even the whole group is to be ignored after parsing, and that's a very significant drawback.
I saw the start\end group but I couldn't find any information on those and how to use them.Your point about skipping fields makes sense.I think it is also solvable with applying the same idea of chunked encoding, even on sub fields.So instead of writing the full length of the child field, you allow the serializer to write it in smaller chunks.The deserializer can then just read the chunk markings and skip them.A very basic serializer can put just one chunk (which will be equivalent to the current implementation, plus one more zero marking at the end), but it allows a more efficient serializer to stream data.Regarding adding something to the encoding spec, are you allowing proto2 serializers to call into proto3 deserializers and vice versa?I thought that if you have a protoX server, you expect clients to take the protoX file and generate a client out of it, which will match that proto version encoding. Isn't it the case?