Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

[Nicolas DORIER <nicolas.dorier@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 --]