Re: [protobuf] [golang] API provides no way to access unknown extensions

['Feng Xiao' via 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 
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?
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] [golang] API provides no way to access unknown extensions

[Josh Humphries]

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?


*Josh Humphries*
jh...@bluegosling.com

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.