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.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.
