path: root/d0/f8da322bc94ae69a41f9b2bba7a80985b1b534

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <nicolas.dorier@gmail.com>) id 1YGVrR-0005OD-Iy
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Jan 2015 16:53:01 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.180 as permitted sender)
	client-ip=74.125.82.180; envelope-from=nicolas.dorier@gmail.com;
	helo=mail-we0-f180.google.com; 
Received: from mail-we0-f180.google.com ([74.125.82.180])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YGVrP-0003ng-Vx
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Jan 2015 16:53:01 +0000
Received: by mail-we0-f180.google.com with SMTP id m14so21966116wev.11
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 28 Jan 2015 08:52:55 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.101.73 with SMTP id fe9mr9030187wib.15.1422463974927;
	Wed, 28 Jan 2015 08:52:54 -0800 (PST)
Sender: slashene@gmail.com
X-Google-Sender-Delegation: slashene@gmail.com
Received: by 10.194.92.112 with HTTP; Wed, 28 Jan 2015 08:52:54 -0800 (PST)
In-Reply-To: <CAJHLa0Mu3Mjn=N-fTQ_fjwp+NUpfBqpdnXZiHoKz1s3tcZa+Cg@mail.gmail.com>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
	<alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
	<CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
	<CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com>
	<CAJHLa0Mu3Mjn=N-fTQ_fjwp+NUpfBqpdnXZiHoKz1s3tcZa+Cg@mail.gmail.com>
Date: Wed, 28 Jan 2015 17:52:54 +0100
X-Google-Sender-Auth: GVtb-u5SkIydajpkrOATl62yNHA
Message-ID: <CALYO6Xs_20YpKeqmtu8N6Vt2uCSV4hM6S=6=zLhfBb_GCyuikg@mail.gmail.com>
From: Nicolas DORIER <nicolas.dorier@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=f46d041826b6ee7307050db933d5
X-Spam-Score: -0.6 (/)
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
	(nicolas.dorier[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1YGVrP-0003ng-Vx
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: Wed, 28 Jan 2015 16:53:01 -0000

--f46d041826b6ee7307050db933d5
Content-Type: text/plain; charset=UTF-8

For the number of field there is in the spec, I don't consider having a
JSON to schama really worthwhile.
If you fear it is error prone, then we should provide some testing data for
the BIP70. (Which I already did for protobuf, but was rejected, because
deemed no useful thanks to the code generator... But such code generator
gave me inconsistencies with gavin's implementation for example)

Why do you think type support is very useful in our case ? we have 3 types,
and dealing only with bytes, int, and string.
It cost me more time to find a suitable cross plateform lib for protobuf
(in c#, that works in ios and winrt) than I would by just coding the json
wrapper classes by hand. (JSON libs are more wildspread and supported than
protobuf)

2015-01-28 17:04 GMT+01:00 Jeff Garzik <jgarzik@bitpay.com>:

> Not to mention the tiresome and error-prone task of writing your own
> JSON-to-schema marshalling code -- or something equivalent to the protobufs
> compiler and libs for JSON.
>
> protobufs -- and its modern competitors such as msgpack -- natively
> provide type support in a way that must be hacked into JSON or XML.
>
> The protobuf/msgpack design is engineered to avoid bugs routinely found in
> JSON parsing code; due to the amount of code & effort involved in JSON
> input sanity checking, bugs and inconsistencies inevitable arise.  We have
> seen this in bitcoind with JSON-RPC.
>
>
>
> On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> On the other hand, if you charge the developer (and not the plateform) to
>>> check certificate validity, it means that you have to develop a different
>>> codebase for all plateform you are targeting, because each plateform store
>>> trusted root certificate in a different manner with different APIs, and
>>> also have different types representing a X509 Certificate.
>>>
>>
>> That's what cross-platform abstraction libraries are for. Both Java and
>> Qt provide a key store library that can load from either the OS root store
>> or a custom one. If your chosen app platform doesn't, OK, then you'll have
>> to make or find one yourself. Perhaps contribute it upstream or make it a
>> library. But that's not a limitation of BIP70.
>>
>> Just as a reminder, there is no obligation to use the OS root store. You
>> can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
>> etc stores and load it in your app. We do this in bitcoinj by default to
>> avoid cases where BIP70 requests work on some platforms and not others,
>> although the developer can easily override this and use the OS root store
>> instead.
>>
>> Of all possible solutions, using a third party service to convert things
>> to JSON is one of the least obvious and highest effort. I don't know anyone
>> else who arrived at such a conclusion and respectfully disagree that this
>> is a problem with the design choices in BIP70. It sounds like a bizarre
>> hack around lack of features in whatever runtime you're using.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>

--f46d041826b6ee7307050db933d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>For the number of field there is in the spec, I don&#=
39;t consider having a JSON to schama really worthwhile.<br></div>If you fe=
ar it is error prone, then we should provide some testing data for the BIP7=
0. (Which I already did for protobuf, but was rejected, because deemed no u=
seful thanks to the code generator... But such code generator gave me incon=
sistencies with gavin&#39;s implementation for example)<br><div><div><div><=
br></div><div>Why do you think type support is very useful in our case ? we=
 have 3 types, and dealing only with bytes, int, and string.<br></div><div>=
It cost me more time to find a suitable cross plateform lib for protobuf (i=
n c#, that works in ios and winrt) than I would by just coding the json wra=
pper classes by hand. (JSON libs are more wildspread and supported than pro=
tobuf)<br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">2015-01-28 17:04 GMT+01:00 Jeff Garzik <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.com</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Not=
 to mention the tiresome and error-prone task of writing your own JSON-to-s=
chema marshalling code -- or something equivalent to the protobufs compiler=
 and libs for JSON.<br><br></div>protobufs -- and its modern competitors su=
ch as msgpack -- natively provide type support in a way that must be hacked=
 into JSON or XML.<br><br></div>The protobuf/msgpack design is engineered t=
o avoid bugs routinely found in JSON parsing code; due to the amount of cod=
e &amp; effort involved in JSON input sanity checking, bugs and inconsisten=
cies inevitable arise.=C2=A0 We have seen this in bitcoind with JSON-RPC.<b=
r><br><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote"><div><div class=3D"h5">On Wed, Jan 28, 2015 at 10:42 AM, Mike Hea=
rn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blan=
k">mike@plan99.net</a>&gt;</span> wrote:<br></div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><div>On the other hand, if you charge the
 developer (and not the plateform) to check certificate validity, it=20
means that you have to develop a different codebase for all plateform=20
you are targeting, because each plateform store trusted root certificate
 in a different manner with different APIs, and also have different=20
types representing a X509 Certificate.<br></div></div></div></blockquote><d=
iv><br></div></span><div>That&#39;s what cross-platform abstraction librari=
es are for. Both Java and Qt provide a key store library that can load from=
 either the OS root store or a custom one. If your chosen app platform does=
n&#39;t, OK, then you&#39;ll have to make or find one yourself. Perhaps con=
tribute it upstream or make it a library. But that&#39;s not a limitation o=
f BIP70.</div><div><br></div><div>Just as a reminder, there is no obligatio=
n to use the OS root store. You can (and quite possibly should) take a snap=
shot of the Mozilla/Apple/MSFT etc stores and load it in your app. We do th=
is in bitcoinj by default to avoid cases where BIP70 requests work on some =
platforms and not others, although the developer can easily override this a=
nd use the OS root store instead.</div><div>=C2=A0</div><div>Of all possibl=
e solutions, using a third party service to convert things to JSON is one o=
f the least obvious and highest effort. I don&#39;t know anyone else who ar=
rived at such a conclusion and respectfully disagree that this is a problem=
 with the design choices in BIP70. It sounds like a bizarre hack around lac=
k of features in whatever runtime you&#39;re using.</div><div><br></div></d=
iv></div></div>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
Dive into the World of Parallel Programming. The Go Parallel Website,<br>
sponsored by Intel and developed in partnership with Slashdot Media, is you=
r<br>
hub for all things parallel software development, from weekly thought<br>
leadership blogs to news, videos, case studies, tutorials and more. Take a<=
br>
look and join the conversation now. <a href=3D"http://goparallel.sourceforg=
e.net/" target=3D"_blank">http://goparallel.sourceforge.net/</a><br>_______=
________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888"><br><=
br clear=3D"all"><br>-- <br><div>Jeff Garzik<br>Bitcoin core developer and =
open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https=
://bitpay.com/" target=3D"_blank">https://bitpay.com/</a></div>
</font></span></div>
</blockquote></div><br></div></div></div></div></div></div>

--f46d041826b6ee7307050db933d5--