Re: [protobuf] Type URLs and Any types

[Josh Humphries]

On Thu, Apr 20, 2017 at 2:03 PM, Feng Xiao  wrote:

>
>
> On Wed, Apr 19, 2017 at 5:25 PM, Josh Humphries 
> wrote:
>
>> The protobuf docs for the Any type
>> 
>> talk about the URL being a real URL, where an HTTP GET request will reply
>> with encoded google.protobuf.Type message. The doc further states that
>> URLs with no scheme assume HTTPS (and runtime support that I've seen looks
>> like it intentionally leaves out the scheme when generating type URLs).
>>
>> However, the given URL examples for all well-known types don't work. Any
>> GET request for https://type.googleapis.com/ fails with a 404.
>> The actual example in the Any doc is for google.protobuf.Duration, and
>> https://type.googleapis.com/google.protobuf.Duration simply does not
>> work.
>>
>> I don't necessarily need these to work, but I have written stuff for
>> resolving types per the doc and have no out-of-the-box URLs I can play with
>> to test it.. It seems like an issue that none of the documented examples
>> actually work.
>>
> Can you create an github issue and give more context about how you plan to
> use it? Right now the type service doesn't exist because we find no use
> case of it for our API service stack.
>

I'm actually writing something for dynamic services. It currently uses GRPC
service reflection, but I was looking at supporting the google.protobuf.Api
type, too (first converting Api, Type, and Enum objects into equivalent
descriptors). I was also looking at implementing dynamic type resolution
for Any types the same way: download the Type object, generate a message
descriptor from it, and then use that to de-serialize the payload.

I don't need to implement this for my project. I just figured I would flesh
these things out, for the sake of completeness, since it's part of the spec
in the published documentation on
https://developers.google.com/protocol-buffers/.

So I'd appreciate the docs being updated to reflect reality. If reality is
that there will be no dynamic type resolution strategy and that clients of
Any messages must have all message URLs statically registered in order to
parse the payloads, that's fine. It just needs to be documented that way.


>
>
>>
>> 
>> *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.

Re: [protobuf] Type URLs and Any types

['Feng Xiao' via Protocol Buffers]

On Wed, Apr 19, 2017 at 5:25 PM, Josh Humphries 
wrote:

> The protobuf docs for the Any type
> 
> talk about the URL being a real URL, where an HTTP GET request will reply
> with encoded google.protobuf.Type message. The doc further states that
> URLs with no scheme assume HTTPS (and runtime support that I've seen looks
> like it intentionally leaves out the scheme when generating type URLs).
>
> However, the given URL examples for all well-known types don't work. Any
> GET request for https://type.googleapis.com/ fails with a 404.
> The actual example in the Any doc is for google.protobuf.Duration, and
> https://type.googleapis.com/google.protobuf.Duration simply does not work.
>
> I don't necessarily need these to work, but I have written stuff for
> resolving types per the doc and have no out-of-the-box URLs I can play with
> to test it.. It seems like an issue that none of the documented examples
> actually work.
>
Can you create an github issue and give more context about how you plan to
use it? Right now the type service doesn't exist because we find no use
case of it for our API service stack.


>
> 
> *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.