2 ms·
When I first read about protocol buffers, I was surprised at the similarity to ASN.1/BER: http://en.wikipedia.org/wiki/Basic_Encoding_Rules http://en.wikipedia.
by jbert 15y ago
When I first read about protocol buffers, I was surprised at the similarity to ASN.1/BER: http://en.wikipedia.org/wiki/Basic_Encoding_Rules http://en.wikipedia.org/wiki/Basic_Encoding_Rules
Basically, they're both nested type/length/value data formats with primitives for numerics, strings, etc with an human readable description language and toolsets to auto-generate language types + (de)serialisers etc.
Given that the ASN.1 toolset exists (even if a little dusty, SNMP and X.509 keep it alive) I don't see why google bothered to re-implement.
The FAQ: http://code.google.com/apis/protocolbuffers/docs/faq.html http://code.google.com/apis/protocolbuffers/docs/faq.html mentions ASN.1 but it's main argument (being tied to a particular form of RPC) doesn't apply to ASN.1.
- wladimir 15y agoIndeed, it has all been done before with ASN.1. ASN.1 was invented for the exact same reason: data-efficient, fast communication. Currently it is mainly in use by telecom. I've also wondered why so many re-inventions of the wheel what is basically ASN.1 and did some research: The main reason which I found was that, according to developers, for reimplementation ASN.1 was too complex to get right (it has a big legacy) and that the current toolsets had or not the right license, not the right languages, etc. Also, they didn't like the ASN description syntax.
- uriel 15y agoYou can't be serious, the absurd complexity of ASN.1 is legendary.