[golang] API provides no way to access unknown extensions
57 views
Skip to first unread message
Josh Humphries
Jun 26, 2017, 10:50:42 PM6/26/17
to Protocol Buffers
For messages generates from syntax="proto2" files, there is a way to access unrecognized fields (as the stream of encoded bytes) via the XXX_unrecognized field. But there is no similar way to access unrecognized fields that happened to be in an extension range.
If I were to add an issue to the github project to remedy this (and maybe even send a pull request), would it get serious consideration? Or is it intentional to keep such details completely inaccessible?
More background:
I have a library, protoreflect, that supports runtime-dynamic messages, using descriptors to define the schemas. One thing I want to be able to do is to re-parse the descriptors using a custom registry of runtime-defined extensions (for custom options). But I don't seem to be able to dig these out of an already-parsed descriptor proto.
The use case: I am building a dynamic GRPC stub that works by querying the server for its descriptors (using service reflection). I am providing a CLI that allows users to pass in JSON that gets parsed into the appropriate request message, serialized to the binary format, and sent in a GRPC request. Similar happens for de-serializing the responses and then dumping the message contents in a human-readable text form.
In order to support custom options, I'd like to be able to efficiently extract the unrecognized extensions from descriptors and re-parse them using custom logic, that uses extension field descriptors that were also downloaded from the same server.
For now, it looks like I need to marshal the options message to bytes, and then I could unmarshal it into a dynamic message (I already have support for unmarshalling with a custom registry of extensions). But I was hoping for something more efficient -- like being able to only do this for the unrecognized extensions. (I can already do this for other unrecognized fields thanks to the export XXX_unrecognized field that gets added to generated proto2 message structs).
Thoughts?
Feng Xiao
Jun 27, 2017, 2:31:22 PM6/27/17
to Josh Humphries, Protocol Buffers
I'm not sure if the go team monitors this mailing group. You might get a better chance to reach them by posting an issue to the golang/protobuf github repo.
On Mon, Jun 26, 2017 at 7:49 PM, Josh Humphries <jh...@bluegosling.com> wrote:
For messages generates from syntax="proto2" files, there is a way to access unrecognized fields (as the stream of encoded bytes) via the XXX_unrecognized field. But there is no similar way to access unrecognized fields that happened to be in an extension range.If I were to add an issue to the github project to remedy this (and maybe even send a pull request), would it get serious consideration? Or is it intentional to keep such details completely inaccessible?
I know very little about Go, but in other languages like C++/Java, unknown extensions are put in the same UnknownFieldSet as other fields. It probably makes more sense to put unknown extensions in XXX_unrecognized?
More background:I have a library, protoreflect, that supports runtime-dynamic messages, using descriptors to define the schemas. One thing I want to be able to do is to re-parse the descriptors using a custom registry of runtime-defined extensions (for custom options). But I don't seem to be able to dig these out of an already-parsed descriptor proto.The use case: I am building a dynamic GRPC stub that works by querying the server for its descriptors (using service reflection). I am providing a CLI that allows users to pass in JSON that gets parsed into the appropriate request message, serialized to the binary format, and sent in a GRPC request. Similar happens for de-serializing the responses and then dumping the message contents in a human-readable text form.In order to support custom options, I'd like to be able to efficiently extract the unrecognized extensions from descriptors and re-parse them using custom logic, that uses extension field descriptors that were also downloaded from the same server.For now, it looks like I need to marshal the options message to bytes, and then I could unmarshal it into a dynamic message (I already have support for unmarshalling with a custom registry of extensions). But I was hoping for something more efficient -- like being able to only do this for the unrecognized extensions. (I can already do this for other unrecognized fields thanks to the export XXX_unrecognized field that gets added to generated proto2 message structs).Thoughts?
--
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+unsubscribe@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.
Josh Humphries
Jun 27, 2017, 3:27:26 PM6/27/17
to Feng Xiao, Protocol Buffers
Will do. Thanks!
Reply all
Reply to author
Forward
0 new messages