21–30 of 71 posts
Consider if IPv4 source and destination addresses in IP datagrams were textual rather than 32-bit fields. IPv6 might not be necessary, NAT might not never have had to be hacked on to the Internet, and most of the centralized cloud model that is pervasive today may just not have had an opportunity to take hold.
Earlier quoted context omitted.
I was a bit surprised myself that the author prefers JSON to bit-packed protocols, but given that the author is none other than Eric Raymond, I have to take him seriously. Accidentally, in my work lately I used JSON for data exchange over the network where performance is not important, and MsgPack otherwise where it is (which is essentially a packed JSON).
I feel like the fact that it's ESR causes me to take him less seriously. I'm basing that on the other contents of his blog, such as http://esr.ibiblio.org/?p=7239 , http://esr.ibiblio.org/?p=26 , and http://esr.ibiblio.org/?p=6907 .
So, when can we expect his JSON serialisation of TLS?
Earlier quoted context omitted.
I was a bit surprised myself that the author prefers JSON to bit-packed protocols, but given that the author is none other than Eric Raymond, I have to take him seriously. Accidentally, in my work lately I used JSON for data exchange over the network where performance is not important, and MsgPack otherwise where it is (which is essentially a packed JSON).
I use CBOR, which is a really nice binary Json. I use it for a custom protocol for embedded systems and it's just brilliant.
Having written trading applications with binary, JSON, and FIX protocols: this article is fucking terrible. 1) scanf on a floating point number works differently on different platforms. If you explore the space of numbers that are expressible, you will find very different results in terms of floating point error depending on which implementation you use. Therefore transmitting floating point in ascii is just asking f…
That reminds me of the Mork file format. Apparently, the edict from management was that the database file format should be space-efficient and human readable. This is to store essentially an entity-attribute-value relationship. The resulting file looks like this: (^a0^23fca)(^a1^23fcb)(^a2^23fcc)... totally unreadable. And it's not particularly efficient as a file format either as a result.
Earlier quoted context omitted.
I feel like the fact that it's ESR causes me to take him less seriously. I'm basing that on the other contents of his blog, such as http://esr.ibiblio.org/?p=7239 , http://esr.ibiblio.org/?p=26 , and http://esr.ibiblio.org/?p=6907 .
We don't even need to get into his (execrable) politics; he's substantively bad on technical issues as well. http://esr.ibiblio.org/?p=6839
> This was a question which I had, believe it or not, never thought about before. But it’s a reasonable one to ask...
That is precious.
Having written trading applications with binary, JSON, and FIX protocols: this article is fucking terrible. 1) scanf on a floating point number works differently on different platforms. If you explore the space of numbers that are expressible, you will find very different results in terms of floating point error depending on which implementation you use. Therefore transmitting floating point in ascii is just asking f…
There is clearly an efficiency downside to packing this description into the messages themselves when the recipient software will necessarily have the protocol information necessary to decode it.