rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-01-19 📝 Original message:The engineers at Google were well aware that ASN.1 existed. I can assure you of that, because I was one of them. The protobuf FAQ has a very polite take on the matter: https://developers.google.com/protocol-buffers/docs/faq This email thread gives more enlightenment: https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 Anyone who has actually had to work with both ASN.1 and protocol buffers will be able to explain why ASN.1 should not be chosen for any modern formats. A lot of it boils down to simplicty and quality of implementations, especially open source implementations. With respect to the specific concerns Richard raises: Performance doesn't feel that relevant when you think that: > Performance wasn't a concern. > 2. One would be cramming this data into a binary format just so you can > then attach it to a no-so-binary format such as HTTP. > HTTP transmits files as binary on the wire. So it's binary-clean and, moreover, HTTP/2 aka SPDY is fully binary and doesn't use text anywhere except the gzip dictionary. > 2. There are tons of great open source libraries and API for parsing / > manipulating / generating. > Luckily, this is also true of protocol buffers. Language support is pretty good these days. > 4. The standards are much easier to read and write. They don't need to > contain code like BIP-0070 currently does and they can contain examples, > which BIP70 does not. > BIP 70 doesn't contain any code, as far as I know. The protobuf schema might look like code, but it's not - it's just a description of what fields a message can contain and their types. This is very relevant for a specification! JSON in particular is pretty awful and I don't like it much. It suffers complexities with things as basic as encoding numbers and strings. It's very much unsuited to applications where correctness matters and where you're dealing with binary structures. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/e6a76662/attachment.html>