Protocol Buffers v3.0.0 released
github.com
Protocol Buffers v3.0.0 released
1–10 of 131 posts
Re: Protocol Buffers v3.0.0 released
#2Wow, this seems to address a bunch of problems I've experienced with protobuf in the past. Looks awesome!
Re: Protocol Buffers v3.0.0 released
#3Wow, this seems to address a bunch of problems I've experienced with protobuf in the past. Looks awesome!
Could you expand on the problems you encountered?
Re: Protocol Buffers v3.0.0 released
#4This looks like a nice evolution.
It's a pity that the "deterministic serialization" gives so few guarantees; I have worked on at least one project that really needed this.
(Basically, we wanted to parse a signed blob, do some work, and pass the original data on without breaking the signature; unfortunately, this requires keeping the serialized form around, since the serialized form cannot be re-generated from its parsed format.)
Re: Protocol Buffers v3.0.0 released
#5"The main intent of introducing proto3 is to clean up protobuf before pushing
the language as the foundation of Google's new API platform"
Does anyone know if this means Google's public APIs will be proto3 based? I quite like protobufs.
Re: Protocol Buffers v3.0.0 released
#6"The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform" Does anyone know if this means Google's public APIs will be proto3 based? I quite like protobufs.
[deleted]
Re: Protocol Buffers v3.0.0 released
#7Google also has flatbuffers. I wonder if flatbuffers is being used by enough developers to justify significant development?
Re: Protocol Buffers v3.0.0 released
#8"The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform" Does anyone know if this means Google's public APIs will be proto3 based? I quite like protobufs.
[deleted]
Re: Protocol Buffers v3.0.0 released
#9> primitive fields set to default values (0 for numeric fields, empty for string/bytes fields) will be skipped during serialization.
I don't totally understand this. Presumably during deserialization they will be set to defaults and not missing? Otherwise, coupled with the removal of required fields, it seems impossible to actually send a 0-value number or empty string, or to send a proto without a field and not have it set to 0 or "" (have to explicitly null the field?).
Re: Protocol Buffers v3.0.0 released
#10> primitive fields set to default values (0 for numeric fields, empty for string/bytes fields) will be skipped during serialization. I don't totally understand this. Presumably during deserialization they will be set to defaults and not missing? Otherwise, coupled with the removal of required fields, it seems impossible to actually send a 0-value number or empty string, or to send a proto without a field and not have…
Within the API, proto3 does not have the concept of field presence. All fields are "present" and default to their type's zero value.
Since the client can handle this, there is no need to explicitly serialize default values.