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