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 <[email protected]> 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 > <https://godoc.org/github.com/jhump/protoreflect/dynamic>, 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? > > ---- > *Josh Humphries* > [email protected] > > -- > 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. > -- 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.
