public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay.com>
To: Nicolas DORIER <nicolas.dorier@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 12:29:53 -0500	[thread overview]
Message-ID: <CAJHLa0MCyzm_t47R5Z5MPL9ruqM=uq15u26W3dwRsBy57K11=w@mail.gmail.com> (raw)
In-Reply-To: <CALYO6Xs_20YpKeqmtu8N6Vt2uCSV4hM6S=6=zLhfBb_GCyuikg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4451 bytes --]

It is not "fear", it is field experience.

JSON has proven to be a bug generator for the reasons already stated.

JSON does not include type marshalling and input validation.
Protobufs/msgpack/etc. engineered those to occur automatically, because
that is an area shown by field experience to be a constant source of bugs
and inconsistent parsing/validation behavior.




On Wed, Jan 28, 2015 at 11:52 AM, Nicolas DORIER <nicolas.dorier@gmail.com>
wrote:

> 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/
>>
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 6296 bytes --]

  reply	other threads:[~2015-01-28 17:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 12:45 [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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
2015-01-19 19:38   ` Jeff Garzik

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='CAJHLa0MCyzm_t47R5Z5MPL9ruqM=uq15u26W3dwRsBy57K11=w@mail.gmail.com' \
    --to=jgarzik@bitpay.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=nicolas.dorier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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