From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YDI8f-0000e7-Vf for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:37:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.178 as permitted sender) client-ip=209.85.212.178; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f178.google.com; Received: from mail-wi0-f178.google.com ([209.85.212.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YDI8e-0005XZ-4s for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:37:29 +0000 Received: by mail-wi0-f178.google.com with SMTP id em10so8031111wid.5 for ; Mon, 19 Jan 2015 11:37:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.203.199 with SMTP id ks7mr61603792wjc.105.1421696242120; Mon, 19 Jan 2015 11:37:22 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Mon, 19 Jan 2015 11:37:22 -0800 (PST) In-Reply-To: <2109963.TWzmcrtnFv@crushinator> References: <2109963.TWzmcrtnFv@crushinator> Date: Mon, 19 Jan 2015 20:37:22 +0100 X-Google-Sender-Auth: Y7MkAKERoElrDZFYfjGqZ3-B44k Message-ID: From: Mike Hearn To: Matt Whitlock Content-Type: multipart/alternative; boundary=047d7b6d9bf27d7fff050d067394 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YDI8e-0005XZ-4s Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:37:30 -0000 X-List-Received-Date: Mon, 19 Jan 2015 19:37:30 -0000 --047d7b6d9bf27d7fff050d067394 Content-Type: text/plain; charset=UTF-8 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. --047d7b6d9bf27d7fff050d067394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The engineers at Google were well aware that ASN.1 existed= . I can assure you of that, because I was one of them.

<= div>The protobuf FAQ has a very polite take on the matter:

=C2=A0 =C2=A0https://developers.google.com/protocol-buffers/docs/faq<= /div>

This email thread gives more enlightenment:
<= div>

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 si= mplicty and quality of implementations, especially open source implementati= ons.

With respect to the specific concerns R= ichard raises:

Performance doesn't feel that relevant when you t= hink that:

Performance wasn't a c= oncern.
=C2=A0
2. One would b= e cramming this data into a binary format just so you can then attach it to= a no-so-binary format such as HTTP.=C2=A0
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 t= ext anywhere except the gzip dictionary.
=C2=A0
2. There are tons of great= open source libraries and API for parsing / manipulating / generating.

Luckily, this is also true of protocol b= uffers. Language support is pretty good these days.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
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.=C2=A0

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. T= his is very relevant for a specification!

JSON in = particular is pretty awful and I don't like it much. It suffers complex= ities with things as basic as encoding numbers and strings. It's very m= uch unsuited to applications where correctness matters and where you're= dealing with binary structures.
--047d7b6d9bf27d7fff050d067394--