diff options
| author | Nicolas DORIER <nicolas.dorier@gmail.com> | 2015-01-28 17:52:54 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-01-28 16:53:01 +0000 |
| commit | a71325aa2d87e51939e70e3c0f3a44514c67722e (patch) | |
| tree | e1fda52ad21dcbd75e58d78bf8a6c8c43666023a /d0 | |
| parent | 500bd0621939a18b40ab41be0d3b42199569c706 (diff) | |
| download | pi-bitcoindev-a71325aa2d87e51939e70e3c0f3a44514c67722e.tar.gz pi-bitcoindev-a71325aa2d87e51939e70e3c0f3a44514c67722e.zip | |
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Diffstat (limited to 'd0')
| -rw-r--r-- | d0/f8da322bc94ae69a41f9b2bba7a80985b1b534 | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/d0/f8da322bc94ae69a41f9b2bba7a80985b1b534 b/d0/f8da322bc94ae69a41f9b2bba7a80985b1b534 new file mode 100644 index 000000000..eab0aa9a8 --- /dev/null +++ b/d0/f8da322bc94ae69a41f9b2bba7a80985b1b534 @@ -0,0 +1,237 @@ +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'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"><<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 & 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"><<a href=3D"mailto:mike@plan99.net" target=3D"_blan= +k">mike@plan99.net</a>></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'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't, OK, then you'll have to make or find one yourself. Perhaps con= +tribute it upstream or make it a library. But that'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'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'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-- + + |