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.