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.

Reply via email to