[protobuf] Re: Why to reinvent the wheel ?
As a side note, the company I worked at used ASN.1 for five years to
encode all of its product's communication messages (Using PER
encoding), with what was supposed to be a highly optimized
implementation of ASN.1.
One of my last projects in the company was to try and convert our
encoding method (and the underlying data structure) from ASN.1 to
Protobuf. A project that was estimated to be long and tiring turned
out to be rather easy, eliminating plenty of unnecessary (in protobuf,
but necessary in ASN.1) memory allocations, thus both speeding
performance and decreasing the memory footprint of our product by
50-70% (!).
So yeah, I'll join Kenton's description of Protobuf to be a 'simpler,
cleaner, smaller, faster, more robust and easier-to-understand ASN.1'.
Jon
On Nov 9, 12:59 am, Kenton Varda ken...@google.com wrote:
OK, I looked into this again (something I do once every few years when
someone points it out).
ASN.1 *by default* has no extensibility, but you can use tags, as I see you
have done in your example. This should not be an option. Everything should
be extensible by default, because people are very bad at predicting whether
they will need to extend something later.
The bigger problem with ASN.1, though, is that it is way over-complicated.
It has way too many primitive types. It has options that are not needed.
The encoding, even though it is binary, is much larger than protocol
buffers'. The definition syntax looks nothing like modern programming
languages. And worse of all, it's very hard to find good ASN.1
documentation on the web.
It is also hard to draw a fair comparison without identifying a particular
implementation of ASN.1 to compare against. Most implementations I've seen
are rudimentary at best. They might generate some basic code, but they
don't offer things like descriptors and reflection.
So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller,
faster, more robust, and easier-to-understand ASN.1.
On Mon, Nov 8, 2010 at 9:42 PM, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where the
components are constantly changing.
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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.c
om
.
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] Re: Why to reinvent the wheel ?
Hello again,
On Nov 9, 2:59 am, Kenton Varda ken...@google.com wrote:
OK, I looked into this again (something I do once every few years when
someone points it out).
ASN.1 *by default* has no extensibility, but you can use tags, as I see you
have done in your example. This should not be an option. Everything should
be extensible by default, because people are very bad at predicting whether
they will need to extend something later.
You can extend it even without using tags. I used tags to show a more
similar encoding as Protobuf.
The bigger problem with ASN.1, though, is that it is way over-complicated.
It has way too many primitive types. It has options that are not needed.
The encoding, even though it is binary, is much larger than protocol
buffers'. The definition syntax looks nothing like modern programming
languages. And worse of all, it's very hard to find good ASN.1
documentation on the web.
You saw on my example that syntax is quite similar to that of
protobuf. Yes, it CAN be very complicated, but it doesn't need to be.
You can use it in a simpler way. You are not forced to use all
primitive types. The encoding can be shorter or bigger, depending on
the enconding rules used. PER is a good example of short encoding, if
length is important in a specific project.
And the best part is that all these encodings are STANDARD. Why to
create a propietary implementation if there is a standard?
It is like microsoft using their propietary formats for offiice
documents, instead on open standards.
Wht if tomorrow Microsoft says : Oh, I need something simpler than
ASN.1, so we will create a different model: And then we wil have a
different version of protobuf. And like this, many companies could
develop their own implementations.
It is also hard to draw a fair comparison without identifying a particular
implementation of ASN.1 to compare against. Most implementations I've seen
are rudimentary at best. They might generate some basic code, but they
don't offer things like descriptors and reflection.
Well, Google, with all their resources, could have, instead of
creating something like ASN.1, but different, put some effort
developing some apis, like those from protobuf, but for ASN.1. They
could have supported maybe a subset of full ASN.1, but they would
still be using an standard, and it would be easier to communicate with
existing systems that support ASN.1
So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller,
faster, more robust, and easier-to-understand ASN.1.
Oh, come on, you are not being serious. You can say many of those
things. What do you mean, for instance : faster ??
ASN.1 has no speed. The speed comes from the ASN.1 compiler. More
robust ?? I see there are, like with any development, bugs that are
being fixed. Better to stick with somethign that has been used for
over 20 years, if you think about More robust:
Easier to understand, well, you saw my example, and it is very easy
to understand.
On Mon, Nov 8, 2010 at 9:42 PM, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where the
components are constantly changing.
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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
[protobuf] Re: Why to reinvent the wheel ?
Oh, I just found out that you are the developer. It seems I am not the
only one who thinks you reinvented the wheel :
http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
As someone mentioned there :
The apparent complexity of ASN.1 is largely due to its flexibility -
if you're using only the sort of functionality that pbuffer gives you,
it would be pretty much the same, I would think.
Luis.
On Nov 9, 2:42 am, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where the
components are constantly changing.
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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] Re: Why to reinvent the wheel ?
On Nov 9, 2:42 am, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where the
components are constantly changing.
Unfortunately, you are wrong, it provides forwards and backwards
compatibility, and that is why it is still being used in so many
protoclos, like telecommunications protocols, that keep changing every
year.
Best regards,
Luis
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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] Re: Why to reinvent the wheel ?
On Nov 9, 10:13 am, multijon multi...@gmail.com wrote:
As a side note, the company I worked at used ASN.1 for five years to
encode all of its product's communication messages (Using PER
encoding), with what was supposed to be a highly optimized
implementation of ASN.1.
One of my last projects in the company was to try and convert our
encoding method (and the underlying data structure) from ASN.1 to
Protobuf. A project that was estimated to be long and tiring turned
out to be rather easy, eliminating plenty of unnecessary (in protobuf,
but necessary in ASN.1) memory allocations, thus both speeding
performance and decreasing the memory footprint of our product by
50-70% (!).
Again I must insist about this. ASN.1 doesn't use memory allocations.
It is an abstract language to describe data, like the abstract syntax
created from scratch for protobuf, but so similar to simplified ASN.1.
That is what it means : Abstract Syntax Notation.
Maybe the ASN.1 compiler that you used used too many memory
allocations or was not too fast. There are some very good, like from
OSS Novalka.
But, Google could have sticked to this existing standard, ASN.1, and
develop their own compiler, supporting maybe not all ASN.1, just the
part needed in protobuf. And then we could have the best of both
worlds. A good, simple, fast compiler, that creates simple to use
APIs, and compatible with an already existing standard.
So yeah, I'll join Kenton's description of Protobuf to be a 'simpler,
cleaner, smaller, faster, more robust and easier-to-understand ASN.1'.
I already made my coments on this.
Best regards,
Luis
Jon
On Nov 9, 12:59 am, Kenton Varda ken...@google.com wrote:
OK, I looked into this again (something I do once every few years when
someone points it out).
ASN.1 *by default* has no extensibility, but you can use tags, as I see you
have done in your example. This should not be an option. Everything should
be extensible by default, because people are very bad at predicting whether
they will need to extend something later.
The bigger problem with ASN.1, though, is that it is way over-complicated.
It has way too many primitive types. It has options that are not needed.
The encoding, even though it is binary, is much larger than protocol
buffers'. The definition syntax looks nothing like modern programming
languages. And worse of all, it's very hard to find good ASN.1
documentation on the web.
It is also hard to draw a fair comparison without identifying a particular
implementation of ASN.1 to compare against. Most implementations I've seen
are rudimentary at best. They might generate some basic code, but they
don't offer things like descriptors and reflection.
So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller,
faster, more robust, and easier-to-understand ASN.1.
On Mon, Nov 8, 2010 at 9:42 PM, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where
the
components are constantly changing.
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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.c
om
.
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
Re: [protobuf] Re: Why to reinvent the wheel ?
There are some standards that pack many different ways to put things
under one umbrella. This is because they have been decided by
committee with many different companies involved that all want to
bring in 'their way'. The multitude of ways to encode things with
ASN.1 (why there is more than one ?) or to choose between encoding
with tags or without (from what I gathered from this communication)
means that there are more ways than one to do things.
How worth is a standard of communication if there are a myriad ways to
do things ? You end up with implementations that only support part of
it and suddenly the standard becomes worthless because two different
implementations don't support the same options of doing things on both
sides.
This discussion reminds me of SOAP. In the beginning, there was
XML-RPC - extremely simple way to communicate using XML with some
small shortcomings but a developer could get started in seconds
reading a simple example communication.
Then standard committees came in and started developed SOAP: out came
a 'standard' that easily is printed 5000 pages with all different ways
to encode things in XML, different transport schemes etc. Same problem
for many years: many implementations that all couldn't speak to each
other. Complicated to use (Yes and I wrote a book about it - I'll
never touch SOAP again).
It got a bit better but people moved on and don't use SOAP anymore.
Protocol buffers are simple and there is only one way to do things.
Simplicity usually wins over developers. This is why they developed
Protocol Buffers at Google in the early 2000s. They're putting it out
here for others to use, but you don't have to.
On Tue, Nov 9, 2010 at 06:44, Kalki70 kalki...@gmail.com wrote:
Oh, I just found out that you are the developer. It seems I am not the
only one who thinks you reinvented the wheel :
http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
As someone mentioned there :
The apparent complexity of ASN.1 is largely due to its flexibility -
if you're using only the sort of functionality that pbuffer gives you,
it would be pretty much the same, I would think.
Luis.
On Nov 9, 2:42 am, Kenton Varda ken...@google.com wrote:
My understanding of ASN.1 is that it has no affordance for forwards- and
backwards-compatibility, which is critical in distributed systems where the
components are constantly changing.
On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 kalki...@gmail.com wrote:
Hello,
I just discovered this developers tool, and I can't understand why it
was invented. Why didn't Google use ASN.1, which is standard and it is
used for this, to make a language, platform independent description of
data to be enconded later as XML, or different binary formats, that
can be faster and more efficient?
All this is like reinventing ASN.1
For instance, the example shown on the web page :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
In ASN.1, which is a standard used for over 20years, the same could be
written similar to this (I haven't used it in a while, maybe I made
some mistakes ):
PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
PhoneNumber ::= SEQUENCE
{
number [1] IA5String ,
phone [2] PhoneType DEFAULT HOME
}
Person ::= SEQUENCE
{
name [1] IA5String ,
id [2] INTEGER,
email [3] OCTET STRING OPTIONAL
phone [4] SET OF PhoneNumber
}
Best regards,
Luis
--
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.
--
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] WSDL Vs PB
In typical WS-* webservice, WSDL describes a service interface, abstracts from underlying communication protocol and serialization and deserialization as well as service implementation platform. Where does PB fits in this picture? Is .proto file, equivalent to WSDL? Or should i view it as simply serialization and deserialization description file ? -- 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] 'python setup.py test' failed
As told in protobuf-2.3.0/python/README.TXT, I run '$python setup.py test'. However failed as bellow: /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'namespace_packages' warnings.warn(msg) /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg) usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'test' What's the problem? -- 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] python enum values option
Hi, I'm stuck with getting the enum value option in Python. The proto
file is:
import descriptor.proto;
extend google.protobuf.EnumValueOptions {
optional string verbose_enum_value_option = 50005;
}
enum ErrorType {
OK = 1 [(verbose_enum_value_option) = OK];
SOME_ERROR = 2 [(verbose_enum_value_option) = Some Error verbose
message];
}
message Request {
required bool success = 1;
optional ErrorType error = 2;
}
When I receive the Request message, I can access the 'error' field,
and its type is int, that's actually ok. But how can I get the
verbose_enum_value_option of 'error' field value ?
Thanks
p.s. The goal is to keep error types and their verbose error messages
in one place, available for every service in our project, so the error
messages would've been identical.
--
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] Re: Why to reinvent the wheel ?
On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 kalki...@gmail.com wrote: On Nov 9, 2:59 am, Kenton Varda ken...@google.com wrote: OK, I looked into this again (something I do once every few years when someone points it out). ASN.1 *by default* has no extensibility, but you can use tags, as I see you have done in your example. This should not be an option. Everything should be extensible by default, because people are very bad at predicting whether they will need to extend something later. You can extend it even without using tags. I used tags to show a more similar encoding as Protobuf. Without tags it is not extensible in the same sense as protocol buffers. The bigger problem with ASN.1, though, is that it is way over-complicated. It has way too many primitive types. It has options that are not needed. The encoding, even though it is binary, is much larger than protocol buffers'. The definition syntax looks nothing like modern programming languages. And worse of all, it's very hard to find good ASN.1 documentation on the web. You saw on my example that syntax is quite similar to that of protobuf. Yes, it CAN be very complicated, but it doesn't need to be. You can use it in a simpler way. You are not forced to use all primitive types. You are looking at it merely from the perspective of someone wishing to use ASN.1, not someone implementing it. The problem is the complexity of implementing ASN.1 in itself brings with it a number of shortcomings. The encoding can be shorter or bigger, depending on the enconding rules used. PER is a good example of short encoding, if length is important in a specific project. PER's encoding of ints is a great example of ASN.1's disadvantages. Most of the compactness in PER severely limits extensibility, as it relies on the decoder having a complete knowledge of the encoded data structure. Even in such cases, if you have fields which normally have small values (2^21 or less) but occasionally may have larger values (and this is a pretty common scenario), the protocol buffer encoding mechanism is going to be much more compact. Even outside of that case, the sheer number of types supported by ASN.1 requires that in order for PER encodings to be extensible, the preamble for fields must take up far more space than it does with protocol buffers. And the best part is that all these encodings are STANDARD. Why to create a propietary implementation if there is a standard? I think this question has already been answered, but it is worth pointing out that the fact that the market place of ideas has produced Hessian, Avro, Thrift, etc., suggests there It is like microsoft using their propietary formats for offiice documents, instead on open standards. No, it actually is quite different. The initial implementation of PB was meant for encoding data that was not to be shared with outside parties (and we are all glad that that data isn't going to be shared). Secondly, the PB implementation is far, far simpler than the ASN.1 standard. Finally, Google provides their complete implementation of an encoder/decoder as open source. Wht if tomorrow Microsoft says : Oh, I need something simpler than ASN.1, so we will create a different model: And then we wil have a different version of protobuf. And like this, many companies could develop their own implementations. This is the reality now. It is also hard to draw a fair comparison without identifying a particular implementation of ASN.1 to compare against. Most implementations I've seen are rudimentary at best. They might generate some basic code, but they don't offer things like descriptors and reflection. Well, Google, with all their resources, could have, instead of When protocol buffers were developed, with all their resources wasn't nearly as impressive sounding as it was now. The reality is that Google had very limited resources and more importantly it would have wasted them without realizing any advantage (and certainly realizing several disadvantages) for its business. creating something like ASN.1, but different, put some effort developing some apis, like those from protobuf, but for ASN.1. They could have supported maybe a subset of full ASN.1, but they would still be using an standard, and it would be easier to communicate with existing systems that support ASN.1 I think you are assuming that being able to communicate with existing ASN.1 systems would be one of the goals. That's a pretty huge assumption. But hey, let's assume that for a moment. There are, last I checked, a half dozen encoding formats for ASN.1. Let's say you implemented just one (PER). There are two variants of PER (aligned and not aligned). Even if you restrict yourself to one variant, you still have ~18 different field types to handle. Even if you restrict yourself to a subset of about 5 that represent functionality inside protocol buffers, you have range encodings
Re: [protobuf] Re: Why to reinvent the wheel ?
On Tue, Nov 9, 2010 at 6:21 AM, Kalki70 kalki...@gmail.com wrote: On Nov 9, 10:13 am, multijon multi...@gmail.com wrote: As a side note, the company I worked at used ASN.1 for five years to encode all of its product's communication messages (Using PER encoding), with what was supposed to be a highly optimized implementation of ASN.1. One of my last projects in the company was to try and convert our encoding method (and the underlying data structure) from ASN.1 to Protobuf. A project that was estimated to be long and tiring turned out to be rather easy, eliminating plenty of unnecessary (in protobuf, but necessary in ASN.1) memory allocations, thus both speeding performance and decreasing the memory footprint of our product by 50-70% (!). Again I must insist about this. ASN.1 doesn't use memory allocations. Yes, but the implementations do. Try getting an ASN.1 implementation as efficient as protocol buffers. It takes a lot more effort than implementing protocol buffers from scratch. That's part of the advantage. There are some very good, like from OSS Novalka. First, they provide about a dozen different products for ASN.1, which by itself saying a lot about ASN.1's complexity. Secondly, the tool isn't available as open source. Additionally, the solution is so cheap that they don't list pricing (I'm trying to remember the pricing the last time I looked at it, but it escapes me). Finally, the last time I tested it, the encode/decode wasn't nearly as fast in C++, let alone Java. There isn't even an implementation for Python or a variety of other languages that have very fast and fully compatible implementations of protocol buffers. Those are some huge advantages for protocol buffers in my mind, despite OSS having devoted far more resources to tackling the problem than everyone collectively has on protocol buffers. -- Chris -- 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] Re: Why to reinvent the wheel ?
On Tue, Nov 9, 2010 at 6:44 AM, Kalki70 kalki...@gmail.com wrote: Oh, I just found out that you are the developer. It seems I am not the only one who thinks you reinvented the wheel : http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html Yes, this is not a new line of thinking. As someone mentioned there : The apparent complexity of ASN.1 is largely due to its flexibility - if you're using only the sort of functionality that pbuffer gives you, it would be pretty much the same, I would think. I think what you are failing to appreciate is that that flexibility in and of itself imposes a huge toll. Think of C vs. C++. -- Chris -- 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] Re: Why to reinvent the wheel ?
On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 kalki...@gmail.com wrote: Well, Google, with all their resources, could have, instead of creating something like ASN.1, but different, put some effort developing some apis, like those from protobuf, but for ASN.1. They could have supported maybe a subset of full ASN.1, but they would still be using an standard, and it would be easier to communicate with existing systems that support ASN.1 As Chris astutely points out, the complexity of ASN.1 makes it much harder to produce a high-quality implementation. Google's resource are not unlimited. Engineering time spend implementing obscure primitive types or other unnecessary features is time NOT spent improving the speed and robustness of the implementation. Oh, come on, you are not being serious. You can say many of those things. What do you mean, for instance : faster ?? ASN.1 has no speed. The speed comes from the ASN.1 compiler. I challenge you, then, to show me an ASN.1 implementation that is faster than our C++ protobuf implementation. Given the 10+-year head start, there should be one, right? More robust ?? I see there are, like with any development, bugs that are being fixed. Better to stick with somethign that has been used for over 20 years, if you think about More robust: There are bugs, but not critical ones. Remember that essentially *all* of Google's server-to-server communications use protobufs. Easier to understand, well, you saw my example, and it is very easy to understand. Sorry, but no. The syntax is not intuitive to C++ or Java developers the way protobuf's syntax is. -- 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] Linkage warning
I don't think this is an issue with protocol buffers as much as it is your specific development environment. The linker is just complaining (http://msdn.microsoft.com/en-us/library/b7whw3f3%28VS.80%29.aspx) that it can't find the debugger .pdb file for the protocol buffers static library. I'm pretty sure this means you won't be able to step inside protocol buffer source files when debugging. Solutions I can think of: 1) Generate a .pdb file by compiling protocol buffers in Visual Studio. See Configuration Properties - Linker - Debugging and set Generate Debug Info to Yes (adds /DEBUG flag) and make sure the Generate Program Data File points somewhere sane. Be sure you don't have multiple projects writing to the same .pdb file, since last write wins. 2) Don't link against the .pdb (see MSDN link above) (you don't want to do this if you are debugging since I believe it will disable debug linking for all libraries, not just protocol buffers). 3) Silence the error by adding /ignore:4099 to the linker command arguments (Properties - Linker - Command Line). 4) Continue ignoring the error. Good luck. Greg -Original Message- From: Jean-Sebastien Stoezel Sent: Saturday, November 06, 2010 11:08 AM To: Protocol Buffers Subject: [protobuf] Linkage warning Hello, I'm using the protobufs 2.3.0 with Visual Studio 2008 I get a few warnings when linking against protobuf.lib (application works fine though): 1LINK : C:\code\myapp.exe not found or not built by the last incremental link; performing full link 1libprotobuf.lib(coded_stream.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(common.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(descriptor.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(descriptor.pb.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(descriptor_database.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(extension_set.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(extension_set_heavy.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(generated_message_reflection.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(message.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(message_lite.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(once.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(reflection_ops.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(repeated_field.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(structurally_valid.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(strutil.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(substitute.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at 'C:\code\myapp\Debug\vc90.pdb'; linking object as if no debug info 1libprotobuf.lib(text_format.obj) : warning LNK4099: PDB 'vc90.pdb' was not found with '.\ThirdParty\protobuf-lib\libprotobuf.lib' or at
[protobuf] fails to parse from string
I have a c++ client/server application that sends messages using protocol buffers, however, at the server side, when i call address_book.ParseFromString(mystr) it returns false, but it actually gets the message correctly from client side, so i am not sure why it thinks that parsing has failed. any ideas? thanks, brad -- 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] fails to parse from string
It sounds like you probably have extra bytes at the end of mystr which are not part of the protobuf. The parser parses everything before those bytes just fine, but then chokes when it gets to the bytes it doesn't recognize. Please make sure you only pass in the exact bytes which came out of the serializer at the other end, no more, no less. On Tue, Nov 9, 2010 at 1:11 PM, Brad Lira snmp.apa...@gmail.com wrote: I have a c++ client/server application that sends messages using protocol buffers, however, at the server side, when i call address_book.ParseFromString(mystr) it returns false, but it actually gets the message correctly from client side, so i am not sure why it thinks that parsing has failed. any ideas? thanks, brad -- 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] python enum values option
You need to use the descriptor for the enum type. Unfortunately this
interface isn't very well fleshed-out in Python. I think you'd have to
write something like:
Request.DESCRIPTOR.fields_by_name['error'].enum_type.values_by_number[message.error].options.Extensions[verbose_enum_value_option]
I haven't checked that that's exactly correct, but it gives you an idea. We
should probably improve this.
On Tue, Nov 9, 2010 at 4:12 AM, Vsevolod Zadubrovsky
zadubrov...@gmail.comwrote:
Hi, I'm stuck with getting the enum value option in Python. The proto
file is:
import descriptor.proto;
extend google.protobuf.EnumValueOptions {
optional string verbose_enum_value_option = 50005;
}
enum ErrorType {
OK = 1 [(verbose_enum_value_option) = OK];
SOME_ERROR = 2 [(verbose_enum_value_option) = Some Error verbose
message];
}
message Request {
required bool success = 1;
optional ErrorType error = 2;
}
When I receive the Request message, I can access the 'error' field,
and its type is int, that's actually ok. But how can I get the
verbose_enum_value_option of 'error' field value ?
Thanks
p.s. The goal is to keep error types and their verbose error messages
in one place, available for every service in our project, so the error
messages would've been identical.
--
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] 'python setup.py test' failed
I haven't seen this problem, but my wild guess is that for some reason your environment is using distutils instead of setuptools. They are similar, but distutils lacks some features, such as the test command. I'm not sure why this would happen, though. On Tue, Nov 9, 2010 at 1:05 AM, cy ora...@gmail.com wrote: As told in protobuf-2.3.0/python/README.TXT, I run '$python setup.py test'. However failed as bellow: /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'namespace_packages' warnings.warn(msg) /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg) usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'test' What's the problem? -- 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] protoc.exe for 2.2.0a
It's the same as 2.2.0. The only change in 2.2.0a affects the runtime library on Linux. On Fri, Nov 5, 2010 at 12:29 PM, Sherry sherr...@gmail.com wrote: Is there a downloadable windows binary for the protoc compiler for 2.2.0a? -- 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] optional imports for protos
Technically, there is no such file google/protobuf/csharp_options.proto. The canonical directory google/protobuf should contain only files from the official Google protobuf implementation. But it seems the C# implementation you're using has chosen to put their own file under this path. I guess that's not a huge deal -- particularly because you're probably using Jon Skeet's implementation and he does technically work for Google -- but I would have asked him to use a different path. Anyway, including the C# options in the Java build should not be a problem. It just requires that you generate Java classes for csharp_options.proto and include those in your application. It's mildly annoying, and we've considered doing something about it, but for the moment this is the only option, as we have no concept of optional imports or compile-time-only imports. On Mon, Nov 8, 2010 at 10:51 AM, jebrick jebr...@gmail.com wrote: I am running into an issue with generating protobuf code for c# and java from the same protos. The protos have an import for the dotnet side (import google/protobuf/csharp_options.proto;) which causes the runtime java code to fail when it tries to generate the Descriptors. Are their any build options to exclude that import for the java_out calls vs a dotnet build? -- 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] link issue with proto in different project
There is a command-line option to add an export macro to all definitions.
Use something like:
protoc --cpp_out=dllexport_decl=MY_EXPORT_MACRO:outdir
However, be very careful when passing protobuf objects across a DLL
boundary. The code on both sides must be dynamically linked against the
same version of the C runtime, otherwise you run into all kinds of binary
compatibility and heap issues. See vsprojects/readme.txt for more
information.
On Fri, Nov 5, 2010 at 1:15 AM, yang yu kojiyij...@gmail.com wrote:
I'm working on windows, some of my projects are dlls.
i need to add __declspec dllexport/dllimport symbol with the function or
variables to use the project as dll.
but when i use protoc generate the source for the proto file, of course
they don't have the dllexport/dllimport symbol.
the problem is after build dll A(have a proto), when i build B link the
project A, i got some link error like this:
error LNK2019: unresolved external symbol void
PB:protobuf_AddDesc_Point2df_2eproto(void)..
because the function void PB:protobuf_AddDesc_Point2df_2eproto(void) in
dll A didn't export,
so the project B link faild.
anything help would be wonderful.
---the situation like
this---
in DLL-A, have a proto like this:
-point.proto-
package PB;
message Point2df
{
required float x = 1;
required float y = 2;
}
in DLL-B, have a proto like this;
-path.proto-
package PB;
import point.proto;
message Path
{
repeated Point2df points = 1;
}
--
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] Re: Why to reinvent the wheel ?
On Nov 9, 6:15 am, Kalki70 kalki...@gmail.com wrote: Hello again, On Nov 9, 2:59 am, Kenton Varda ken...@google.com wrote: [...] The bigger problem with ASN.1, though, is that it is way over-complicated. It has way too many primitive types. It has options that are not needed. The encoding, even though it is binary, is much larger than protocol buffers'. The definition syntax looks nothing like modern programming languages. And worse of all, it's very hard to find good ASN.1 documentation on the web. You saw on my example that syntax is quite similar to that of protobuf. Yes, it CAN be very complicated, but it doesn't need to be. You can use it in a simpler way. You are not forced to use all primitive types. The encoding can be shorter or bigger, depending on the enconding rules used. PER is a good example of short encoding, if length is important in a specific project. And the best part is that all these encodings are STANDARD. Why to create a propietary implementation if there is a standard? It is like microsoft using their propietary formats for offiice documents, instead on open standards. [...] It's not a proprietary implementation if the entire specification and implementation source code can be downloaded by anyone who wants it, not just for C++/Java/Python, but for many other languages as well. It is also hard to draw a fair comparison without identifying a particular implementation of ASN.1 to compare against. Most implementations I've seen are rudimentary at best. They might generate some basic code, but they don't offer things like descriptors and reflection. Well, Google, with all their resources, could have, instead of creating something like ASN.1, but different, put some effort developing some apis, like those from protobuf, but for ASN.1. They could have supported maybe a subset of full ASN.1, but they would still be using an standard, and it would be easier to communicate with existing systems that support ASN.1 I can't speak for Google, but maybe they had no need to communicate with existing systems that support ASN.1. Maybe they were building something from scratch, and therefore had the opportunity to develop something optimal for their particular problems. The thing is that this is just the way of the world, and I think it's a good thing. Imagine if nobody ever said to themselves, I know there is an XYZ (operating system, RDBMS, web server, ...) out there, but maybe I can make an implementation that works better for me. I'll call it Linux. Or MySQL, or nginx, or who knows what. And I'm sure, as those systems were built, the authors had to deal with people asking them why they were reinventing the wheel. So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller, faster, more robust, and easier-to-understand ASN.1. Oh, come on, you are not being serious. You can say many of those things. What do you mean, for instance : faster ?? ASN.1 has no speed. The speed comes from the ASN.1 compiler. More robust ?? I see there are, like with any development, bugs that are being fixed. Better to stick with somethign that has been used for over 20 years, if you think about More robust: I think faster in this case refers to the run time performance of the generated code, in terms of encoding and decoding a particular block of structured data. With regard to bugs, I've been using the C++ protobuf implementation provided by Google for about a year and a half, and I have never experienced a crash or bug of any kind, through many, many terabytes of protobuf I/O, tens of billions of messages with multiple levels of nested submessages and dozens of fields. So as far as I am concerned, that is robust enough for me. And if I have any questions about the way the implementation works, I can just go look at the code. The simplicity of the specification and implementation are a huge advantage there. -dave -- 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] Re: omitting tag numbers
On Mon, Oct 25, 2010 at 4:11 PM, Henner Zeller henner.zel...@googlemail.com wrote: On Mon, Oct 25, 2010 at 16:10, maninder batth batth.manin...@gmail.com wrote: I disagree. You could encode field name in the binary. Then at de- serialization, you can read the field descriptor and reconstruct the field. There is absolutely no need for tags. They are indeed cumbersome. If you include the field name, then your throw out part of the advantages of protocol buffers out of the window: speed and compact binary encoding. This aspect could be mostly mitigated by integrating a metadata header in to files. For systems with this kind of an approach look at Avro Hessian. -- Chris -- 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] WSDL Vs PB
On Tue, Nov 9, 2010 at 7:56 AM, maninder batth batth.manin...@gmail.comwrote: In typical WS-* webservice, WSDL describes a service interface, abstracts from underlying communication protocol and serialization and deserialization as well as service implementation platform. Where does PB fits in this picture? Is .proto file, equivalent to WSDL? Or should i view it as simply serialization and deserialization description file ? The .proto could serve this role, or you could use a FileDescriptorSet PB. -- Chris -- 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.
