Will do. Thanks! ---- *Josh Humphries* [email protected]
On Tue, Jun 27, 2017 at 2:31 PM, Feng Xiao <[email protected]> wrote: > 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.
