[protobuf] Re: Transfer actual code with Protobuffers

On Tuesday, May 30, 2017 at 11:18:30 AM UTC-7, Alex TS wrote: > > Hey everyone, > I'm quite new to Protocol Buffers and don't really have a background on > the theme, so pardon me if this sounds absurd or if this is not the right > forum. > > With that out of the way, if I'd like to transfer

[protobuf] https://groups.google.com/d/topic/protobuf/ofdOcxt6zs8/discussion

https://groups.google.com/forum/?hl=en#!forum/dotnetopenid https://groups.google.com/d/topic/protobuf/ofdOcxt6zs8/discussion -- 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,

Re: [protobuf] Transfer actual code with Protobuffers

That's not something that protobuf targets. If you have a syntax that allows you to convey an expression as a string or similar, then by all means do that - but protobuf will just see it as an opaque string. Note that there are usually a range of concerns when transferring executable code (of any

[protobuf] Transfer actual code with Protobuffers

Hey everyone, I'm quite new to Protocol Buffers and don't really have a background on the theme, so pardon me if this sounds absurd or if this is not the right forum. With that out of the way, if I'd like to transfer say, a method, from the server to execute on the client. Is that possible at

Re: [protobuf] Detecting unknown field in raw message

understood. Many thanks for the answers! On Tuesday, 30 May 2017 20:48:34 UTC+3, Adam Cozzette wrote: > > Here is a doc with the rough plan for reintroducing unknown field > preservation: > https://docs.google.com/document/d/1KMRX-G91Aa-Y2FkEaHeeviLRRNblgIahbsk4wA14gRk/edit?usp=sharing > I

Re: [protobuf] Detecting unknown field in raw message

Here is a doc with the rough plan for reintroducing unknown field preservation: https://docs.google.com/document/d/1KMRX-G91Aa-Y2FkEaHeeviLRRNblgIahbsk4wA14gRk/edit?usp=sharing I am not sure what the Go API for accessing the unknown fields will look like, though. I would again recommend against

Re: [protobuf] Detecting unknown field in raw message

> > Another thing to keep in mind is that we are planning to reintroduce > support for preserving unknown fields in proto3, so the behavior around > unknown fields is going to change soon. > Can you elaborate on this as well please? Does that mean that given a schema S1 that is a sub-schema

Re: [protobuf] Detecting unknown field in raw message

On Tue, May 30, 2017 at 9:06 AM, Yacov Manevich wrote: > but there are some corner cases where that would not be true >> > > Can you elaborate please? > Sure, the main thing is that protocol buffers do not have a canonical format, and there are many ways to create a valid

Re: [protobuf] Detecting unknown field in raw message

> > but there are some corner cases where that would not be true > Can you elaborate please? Why do you want to detect which schema was used to serialize the message anyway? because I have a project where we have a distributed system that part of it might be upgraded, but another part might

Re: [protobuf] Detecting unknown field in raw message

I am not that familiar with the Go implementation of protobuf, but my guess is that this would be somewhat difficult to do reliably. If you un-marshal and re-marshal the message and get a smaller size, then usually that would indicate there were some unknown fields, but there are some corner cases

Re: [protobuf] Generating an (C#) Interface and extendable data model from .proto, namespacing and inheritence

Hey Marc, Thanks for the feedback. I'm currently mangling the "official" proto C# generator that was recently ported from https://github.com/jskeet/protobuf-csharp-port by Jon Skeet and brought into the google proto mainline @ https://github.com/google/protobuf/tree/master/csharp As for an

Re: [protobuf] Generating an (C#) Interface and extendable data model from .proto, namespacing and inheritence

I can't speak for the design choices - but *as I understand it*, the key point of protobuf is to enable things to work well cross-platform. That means that at the DTO level, things need to be *possible* to implement in a wide range of languages, and the reality is that not all frameworks would

[protobuf] Generating an (C#) Interface and extendable data model from .proto, namespacing and inheritence

Hi all, I was wondering if any thought has gone into generating an interface to go along with the generated data classes from a proto. And if it had been considered were there any reasons to not do it? Quick sketch of my current situation: I have a project that has a complex and messy internal