On Thu, Mar 17, 2016 at 9:27 PM, Tim Kientzle <kient...@gmail.com> wrote:
> > > On Mar 17, 2016, at 10:04 AM, Feng Xiao <xiaof...@google.com> wrote: > > > > On Wed, Mar 16, 2016 at 7:49 PM, Tim Kientzle <kient...@gmail.com> > wrote: > > > > > On Mar 14, 2016, at 7:07 PM, Feng Xiao <xiaof...@google.com> wrote: > > > > > > In google, we are using a front-end proxy to convert JSON to/from > protobuf, and everything else behind it is using protobuf only. The current > Any design works with this approach very well. > > > > That approach works well my proposed Any design as well. Your proxies > can still walk the object tree and validate and/or convert Any fields as > necessary for your particular systems. > > > > But that approach is not appropriate for everyone. Your Any design > cannot be used by people that require different policies. > > > Can you elaborate a bit more? You mentioned the middle system does not > know google.profile and has no way to get it. Why is that? I think whether > the middle system knows the type info is the only thing that makes a > difference. In the google scenario, the middle system always knows all > types it will be converting from JSON to protobuf and rejects inputs it > doesn't know about. > > One example I’ve been considering is a local logging service that needs to > decode the messages received from various local agents, set standard fields > (system time, etc), and then recode and store it for later forwarding. The > service has no need to know the various attached data for the log entries > it is forwarding. Your current design supports this gracefully for > protobuf coding (Any fields can be decoded and recoded in protobuf without > knowing the schema for the embedded data) but not for JSON. > If protobuf binary format works better, why not just use protobuf binary format? JSON format and protobuf binary format have different advantages and suite different usage scenarios. Proto3 JSON format is not designed as a replacement of protobuf binary format. It's more of motivated by JSON's popularity in defining APIs and it's intended to be used in APIs as an alternative to protobuf binary format (e.g., API clients may not support protobuf at all). In a lot of places, you can't simply switch from protobuf binary format to JSON format and expect it to work exactly the same way. If you are using protobuf in an internal system, it seems always better to just use the protobuf binary format. > > You can certainly not assume that a local service of this sort always has > network access. > Resolving Any type doesn't necessarily require network access. Actually I am not aware of any service that is resolving Any type using a remote type service. The google proxy server I mentioned earlier is also doing all the type resolving against a local type database. Basically all types allowed to be used in the communication must be registered first, and the proxy starts up with all the type info. > > Tim > > -- 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.
