[protobuf] Why to reinvent the wheel ?
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.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Why to reinvent the wheel ?
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.
Re: [protobuf] Why to reinvent the wheel ?
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.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] Why to reinvent the wheel ?
On Mon, Nov 8, 2010 at 9:59 PM, Kenton Varda ken...@google.com wrote: The bigger problem with ASN.1, though, is that it is way over-complicated. THIS 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'. Actually, the PER encoding isn't too bad, although it doesn't encode ints using varint style encoding, which tends to help with most data sets. 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. Yup, this one too. On the plus side, you can find the standards well defined, which helps when building independent 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. Complexity yields rudimentary implementations. So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller, faster, more robust, and easier-to-understand ASN.1. :-) -- 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.
