rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2016-06-21 📝 Original message:On Tue, Jun 21, 2016 at 08:44:37PM +0000, Luke Dashjr via bitcoin-dev wrote: > On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > > BIP 0070 has been a a moderate success, however, IMO: > > > > - protocol buffers are inappropriate since ease of use and extensibility is > > desired over the minor gains of efficiency in this protocol. Not too late > > to support JSON messages as the standard going forward > > IMO JSON is too prone to gratuitous inefficiency (both at network and CPU > level), parser bugs, etc. Even the best C implementation (jansson) has serious > issues with Number handling. > > A few years ago, I looked into binary alternatives to JSON and concluded they > all had problems, while it seems more than reasonable to do even dynamic > parsing of protobuf messages. So to conclude, I prefer to stick to protobuf > unless a clearly superior protocol turns up. I'll second that statement. Ease of use isn't a very good criteria for security-critical software handling money, and the JSON standard has a very large amount of degrees of freedom in how people have implemented it historically. Even protobuf I'd personally avoid using on that basis, as protobuf encoding isn't deterministic: you can encode the same data in multiple ways. Unfortunately there isn't a viable alternative, so we're probably stuck with protobuf right now for standards that want to see wide adoption in the near future; I've got a few projects that need an alternative, which I'm working on, but that's a ways off. -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/ab86e67e/attachment.sig>