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.com<protobuf%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.
