public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nicolas DORIER <nicolas.dorier@gmail•com>
To: Jeff Garzik <jgarzik@bitpay•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 17:52:54 +0100	[thread overview]
Message-ID: <CALYO6Xs_20YpKeqmtu8N6Vt2uCSV4hM6S=6=zLhfBb_GCyuikg@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0Mu3Mjn=N-fTQ_fjwp+NUpfBqpdnXZiHoKz1s3tcZa+Cg@mail.gmail.com>

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

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

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

  reply	other threads:[~2015-01-28 16:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 12:45 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 [this message]
2015-01-28 17:29           ` Jeff Garzik
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='CALYO6Xs_20YpKeqmtu8N6Vt2uCSV4hM6S=6=zLhfBb_GCyuikg@mail.gmail.com' \
    --to=nicolas.dorier@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=jgarzik@bitpay$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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