Re: [protobuf] Re: inheritance.. well sort of... and FieldDescriptors

You can't use the same field descriptors for the four classes. But, note that one thing you *can* do is define a "base" type that just contains the shared fields, and then parse any of the other types as this type in order to access the common fields. Since the field numbers match, they are compa

[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

On Tue, Feb 1, 2011 at 3:17 PM, Jason Hsueh wrote: > Conceptually this sounds great, the big question to me is whether this > should be implemented as an option in the compiler or as a separate plugin. > I haven't taken a thorough look at the patch, but I'd guess it adds a decent > amount to the

RE: [protobuf] Support for generic surrogates, eg. Queue

Yes, I've no problem with releasing it under the existing (Apache 2) license terms. From: Marc Gravell [mailto:marc.grav...@gmail.com] Sent: 01 February 2011 03:18 To: NYCBrit Cc: Protocol Buffers Subject: Re: [protobuf] Support for generic surrogates, eg. Queue Nice - I'm glad that was a

Re: [protobuf] Protocol Buffers Python extension in C

I've implemented code generator so others can test / use our C implementation in Python. Another new thing is Lazy decoding support. Message are decoded on the fly as attributes are accessed for the first time. More info: http://blog.connex.io/introducing-cypb-improving-the-performance-of You ca

[protobuf] Re: New protobuf feature proposal: Generated classes for streaming / visitors

Conceptually this sounds great, the big question to me is whether this should be implemented as an option in the compiler or as a separate plugin. I haven't taken a thorough look at the patch, but I'd guess it adds a decent amount to the core code generator. I have a preference for the plugin appro

Re: [protobuf] Services not compiling

The *_generic_services options now default to false. You must explicitly set them to true, e.g.: option cc_generic_services = true; option java_generic_services = true; option py_generic_services = true; We decided to make these off-by-default because we want to encourage RPC implementatio

[protobuf] Services not compiling

Hi, I'm new to protocol buffers so apologies if this is something stupid. (I searched the forum and didn't find anything). I'm having a problem getting services to compile. I have the following population.proto file: package population; message addrinfo { required fixed32 ip = 1; requir

[protobuf] v2.4 question

Hello. >From what I gather catching up on list messages, 2.4 is final, but not officially released, perhaps because some documentation is in the works. I ask because I would like to incorporate 2.4 in my product's upcoming build cycle, but only if there is reasonable certainty that the bits wo

Re: [protobuf] Repeated Fields Encoding

The encoding is documented in detail here: http://code.google.com/apis/protocolbuffers/docs/encoding.html The short answer is, yes, repeated fields are literally encoded as repeated individual values, unless you use "packed" encoding

[protobuf] New protobuf feature proposal: Generated classes for streaming / visitors

Hello open source protobuf users, *Background* Probably the biggest deficiency in the open source protocol buffers libraries today is a lack of built-in support for handling streams of messages. True, it's not too hard for users to support it manually, by prefixing each message with its size as

Re: [protobuf] Repeated Fields Encoding

I think this also came to me directly and I answered earlier, but this is the expected layout of "repeated" data, where each item in a list is mapped separately in the data stream. Marc On 1 Feb 2011, at 11:01, Timothy Parez wrote: > Hello, > > Considering the following proto file: > > mess

[protobuf] Repeated Fields Encoding

Hello, Considering the following proto file: message FileDescriptor { required string Filename = 1; optional int64 Size = 2 [default = 0]; } message FileList { repeated FileDescriptor Files = 1; } If you create something like this: (and I'm duplicating the data because i

Re: [protobuf] Support for generic surrogates, eg. Queue

Nice - I'm glad that was a v2 patch, though ;p Before I look at that at any length, though, can you confirm that you can freely release this patch under the existing license terms? (just my "CYA") Marc On 1 February 2011 03:03, NYCBrit wrote: > I've made a small modification to add support for

Re: [protobuf] Serializing Dictionary

Both, really. And of course by the time you are embedding **type** metadata into the file you have ceased to be portable (or contract-based). This is potentially something that could be added as a non-portable feature of a single implementation, but *in most cases* there are ways to do it **inside*

Re: [protobuf] Recursion support in Protobuf-net

Yes, that is already on my list of things I really, really want it to do. It will inevitably be in "v2" at some point, but to repeat your point: this will be 100% implementation specific and not generically portable between platforms, so it will have to be by explicit "opt in". Marc On 1 February

Re: [protobuf] Why does protobuf-net append to a byte[] Property/field on deserialize?

I'll see if I can add something when I get chance, but note that you could also work around this by using serialization callbacks to detect when deserialization is starting, and wipe the default BLOB. Also, the elusively unreleased "v2" also optionally supports ctor-skipping (like WCF/DataContract