3 ms·
Seems a little harsh, - it's written somewhat badly, but the comments about endianness are important - sure, a randomly generated 64-bit integer encoded as big
by dedward 16y ago
Seems a little harsh, - it's written somewhat badly, but the comments about endianness are important - sure, a randomly generated 64-bit integer encoded as big-endian is, entropically speaking, no more useful than it's little-endian brother. It's also useless all by itself. As part of a system though, like a challenge/response system, it's important both ends of the system know how to interpret the data they are dealing with - so this is important.
At that point, defining the fact that you are sending a big-endian 64-bit integer It might seem trivial now that we write everything in Java, but endianness caused all kinds of portability problems in the early internet days when we started making different systems talk to each other, and made simple porting jobs difficult. It's how we ended up with network-byte-order instead of just using long ints and stuff like that - it's very easy to overlook.
In short, being specific about data formats matters.
And yeah, it would suck if they over-complicate things - let's not let that happen - we need simple protocols, but not too simple. It's okay if you can slightly abuse them if it means fast adoption (One can coax HTTP servers to sign into IRC and spam channels - but it's not a big enough problem to warrant redesigning the whole thing, right?)
- axod 16y ago> " it's important both ends of the system know how to interpret the data they are dealing with - so this is important." As I say, it's treated, by both sides, as 8 bytes of random data. Never as integers. The endianness here is irrelevant. The spec is going into way more detail than it needs.