From: Mike Hearn <mike@plan99•net>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Mon, 19 Jan 2015 20:37:22 +0100 [thread overview]
Message-ID: <CANEZrP0C__aC8Y643j0oy+mnYB7KqGA8Ry04R5NEqbbkuPxchw@mail.gmail.com> (raw)
In-Reply-To: <2109963.TWzmcrtnFv@crushinator>
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3425 bytes --]
next prev parent reply other threads:[~2015-01-19 19:37 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 19:07 Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16 ` Richard Brady
2015-01-19 19:34 ` Jeff Garzik
2015-01-19 19:48 ` Peter Todd
2015-01-19 19:57 ` Richard Brady
2015-01-19 20:03 ` Alan Reiner
2015-01-19 20:06 ` Peter Todd
2015-01-19 20:40 ` Mike Hearn
2015-01-19 20:56 ` Gavin Andresen
2015-01-19 21:22 ` Brian Hoffman
2015-01-19 20:59 ` Ross Nicoll
2015-01-24 13:19 ` Isidor Zeuner
2015-01-25 22:59 ` Ross Nicoll
2015-03-14 15:58 ` Isidor Zeuner
2015-03-24 12:08 ` Jorge Timón
2015-01-19 21:21 ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37 ` Mike Hearn [this message]
2015-01-19 19:38 ` Jeff Garzik
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER
2015-01-28 15:42 ` Mike Hearn
2015-01-28 16:04 ` Jeff Garzik
2015-01-28 16:52 ` Nicolas DORIER
2015-01-28 17:29 ` Jeff Garzik
2015-01-28 17:45 ` Mike Hearn
2015-01-28 16:19 ` Giuseppe Mazzotta
2015-01-28 16:51 ` Matt Whitlock
2015-01-28 17:02 ` Mike Hearn
2015-01-28 16:34 ` Nicolas DORIER
2015-01-28 16:55 ` Mike Hearn
2015-01-28 17:04 ` Nicolas Dorier
2015-01-28 17:14 ` Mike Hearn
2015-01-28 17:17 ` Angel Leon
2015-01-28 17:27 ` Nicolas DORIER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP0C__aC8Y643j0oy+mnYB7KqGA8Ry04R5NEqbbkuPxchw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox