3 ms·
Protocol buffers already do that; serialized fields that are not recognized by an older message definition are parsed and can be accessed via the "unknown field
by humbledrone 7y ago
Protocol buffers already do that; serialized fields that are not recognized by an older message definition are parsed and can be accessed via the "unknown fields" API, exactly as "r" above. Intermediaries can pass these through trivially, or inspect them to see what they didn't understand.
The problem with making fields required is that older serialized protocol buffers parsed by newer message definitions may be missing newly added required fields, which will break things.
- naasking 7y agoProtobuf does not do this via a typed interface, but via runtime checking.
- joshuamorton 7y agoYou can't statically typecheck deserialized data. You must validate that deserislized value matches the schema, and you can only do so at runtime. In other words, proto has a typed interface, but you must runtime check that a given bag of bytes conforms to that typed interface. This is true for any io.
- naasking 7y ago> You must validate that deserislized value matches the schema, and you can only do so at runtime I assume you mean serialised data, not deserialized. And yes, deserializing includes type checking. The point is that this happens once and the need for a separate API for dynamic data shouldn't be needed.
- joshuamorton 7y agoWhat do you mean by a separate api for dynamic data? The data under discussion isn't "dynamic", it's still static, it just isn't known to the schema in question at runtime (since it's only known to a different schema). That means you can't access it by name, since the field names aren't known.