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.

Reply via email to