[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 it made it easier to spot in a
hex editor)
files.Files.Add(new FileDescriptor() { Filename = AAA, Size =
100 });
files.Files.Add(new FileDescriptor() { Filename = AAA, Size =
100 });
files.Files.Add(new FileDescriptor() { Filename = AAA, Size =
100 });
files.Files.Add(new FileDescriptor() { Filename = AAA, Size =
100 });
and then serialize it using the Protobuf.Serializer I expected it to
generate something like
Tag for the FileList - Id 1, WireType 2 = 0x0A
Length of the payload (all the bytes for all the files that follow)
But instead I found everything is simply repeated.
0A 0B 0A 07 41 41 41 41 41 41 41 10 64
0A 0B 0A 07 41 41 41 41 41 41 41 10 64
0A 0B 0A 07 41 41 41 41 41 41 41 10 64
0A 0B 0A 07 41 41 41 41 41 41 41 10 64
I'm wondering, is this an implementation detail (and allowed by the
protobol buffer specifications)
or a requirement of the google protocol buffer specifications ?
It does seem to add quite a bit of overhead, imagine the FileList has
other properties,
they would be repeated for every instance of FileDescriptor ?
Or am I missing something ?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] What's the point of Protocol Buffers?
Hi, The reason we use it is because we don't just develop software but also hardware solutions. Hardware solutions which are connected through GPRS or even RS232 connections. GPRS is slow and in most cases you pay for the amount of data your send, so we have to keep the packages as small as possible. RS232 doesn't work well with large packets, so again size is very important. Web Services, REST, SOAP, ... they are all very verbose... to expensive/large for our needs. If you need data to be as small as possible, protocol buffers are a good option. Timothy On Wed, Jul 21, 2010 at 12:57 PM, Tim Acheson tim.ache...@gmail.com wrote: I generally create web services using WCF or ASP.NET MVC. I don't get the point of Protocol Buffers. Am I missing something? Out of the box, WCF web services and ASP.NET MVC actions serialise my objects to JSON or XML, using the serialisation libraries provided by the framework. I don't need to do anything to achieve encoding structured data in an efficient yet extensible format -- I just define my objects as normal and the .NET framework does everything for me. I don't need to write any code to do the serialisation, either. I just define the return type of the web method in my WCF project, or define an ASP.NET MVC Action that returns the object. The framework does the rest. Also, I rarely come accross a web service that returns anything other than strings, 32-bit integers and booleans. If I did, I'd probably question the architecture. Perhaps somebody could explain why I would want or need to use Protocol Buffers? Thanks! :) -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] What's the point of Protocol Buffers?
Also note, while your computer might have 4 cores running at 2.5Ghz the hardware I'm talking about has 1 core, runs at 100Mhz and that's it... processing XML on devices like that... a real pain in the ... But I have to admit, when I write computer to computer software, I go REST or SOAP all the way On Sat, Jul 24, 2010 at 1:40 AM, Timothy Parez timothypa...@gmail.comwrote: Hi, The reason we use it is because we don't just develop software but also hardware solutions. Hardware solutions which are connected through GPRS or even RS232 connections. GPRS is slow and in most cases you pay for the amount of data your send, so we have to keep the packages as small as possible. RS232 doesn't work well with large packets, so again size is very important. Web Services, REST, SOAP, ... they are all very verbose... to expensive/large for our needs. If you need data to be as small as possible, protocol buffers are a good option. Timothy On Wed, Jul 21, 2010 at 12:57 PM, Tim Acheson tim.ache...@gmail.comwrote: I generally create web services using WCF or ASP.NET MVC. I don't get the point of Protocol Buffers. Am I missing something? Out of the box, WCF web services and ASP.NET MVC actions serialise my objects to JSON or XML, using the serialisation libraries provided by the framework. I don't need to do anything to achieve encoding structured data in an efficient yet extensible format -- I just define my objects as normal and the .NET framework does everything for me. I don't need to write any code to do the serialisation, either. I just define the return type of the web method in my WCF project, or define an ASP.NET MVC Action that returns the object. The framework does the rest. Also, I rarely come accross a web service that returns anything other than strings, 32-bit integers and booleans. If I did, I'd probably question the architecture. Perhaps somebody could explain why I would want or need to use Protocol Buffers? Thanks! :) -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Basic message encoding/decoding
Hi, I've looked at http://code.google.com/apis/protocolbuffers/docs/encoding.html and while this probably provides all the required information, it still doesn't click for me. Does anybody have any simple code samples which do nothing more than encode and decode a simple message? I'm aware I can simply use one of the various libraries, but it's important I understand basic encoding/decoding so I can pass this knowledge to teams who are using a language which is not supported by any of the libraries. Thnx. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
