1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
<2109963.TWzmcrtnFv@crushinator>
Date: Mon, 19 Jan 2015 20:37:22 +0100
X-Google-Sender-Auth: Y7MkAKERoElrDZFYfjGqZ3-B44k
Message-ID: <CANEZrP0C__aC8Y643j0oy+mnYB7KqGA8Ry04R5NEqbbkuPxchw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Whitlock <bip@mattwhitlock.name>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<div dir=3D"ltr">The engineers at Google were well aware that ASN.1 existed=
. I can assure you of that, because I was one of them.<div><div><br></div><=
div>The protobuf FAQ has a very polite take on the matter:</div><div><br></=
div><div>=C2=A0 =C2=A0<a href=3D"https://developers.google.com/protocol-buf=
fers/docs/faq">https://developers.google.com/protocol-buffers/docs/faq</a><=
/div><div><br></div><div>This email thread gives more enlightenment:</div><=
div><br></div><div>=C2=A0 =C2=A0<a href=3D"https://groups.google.com/forum/=
#!topic/protobuf/eNAZlnPKVW4">https://groups.google.com/forum/#!topic/proto=
buf/eNAZlnPKVW4</a></div><div><br></div><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.</div></div><div><br></div><div>With respect to the specific concerns R=
ichard raises:</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"font-siz=
e:12.8000001907349px">Performance doesn't feel that relevant when you t=
hink that:</div></blockquote><div><br></div><div>Performance wasn't a c=
oncern.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div style=3D"font-size:12.8=
000001907349px"><span style=3D"font-size:12.8000001907349px">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</span></div></blockquote><div><b=
r></div><div>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.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div style=3D"font-size:12.8000001907349px">2. There are tons of great=
open source libraries and API for parsing / manipulating / generating.</di=
v></blockquote><div><br></div><div>Luckily, this is also true of protocol b=
uffers. Language support is pretty good these days.</div><div>=C2=A0</div><=
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"><div style=3D"font-size:12.8000001907349px"><span style=3D"=
font-size:12.8000001907349px">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</span></div></block=
quote><div><br></div><div>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!</div><div><br></div><div>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.</div></div>
--047d7b6d9bf27d7fff050d067394--
|
