Linked by mufasa on Mon 10th Aug 2009 12:25 UTC
Permalink for comment 377993
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
More News »
Sponsored Links



Member since:
2009-06-09
As long as you're encoding the same information, there isn't going to be much difference between a binary format, and a compressed text format. Markup compresses extremely well.
It's not only a network latency/bandwidth problem. Computers don't like compression and text parsing. They will happily do the work, but not very fast.
Think about what happends when sending a compressed HTML/XML:
Sender:
1. Create text in buffer (memory and text creation overhead).
2. Compress the text (cycles and more memory touched).
3. Send data.
Receiver:
4. Receive data.
5. Decompress data.
6. Parse text.
With binary you skip step 2 and 5, while the rest have a smaller overhead.
Then people shout "interoperability" and "human-readable"!
Interoperability: When computers talk to each other they don't care about the encoding as long as they agree on the format.
Human-readable: This is only needed for debugging; then use a debugger! You just need a tool that can transform the binary to a human-readable format.
Imagine if machine code and the TCP/IP headers were text. Would you defend such a design?
Edited 2009-08-11 01:41 UTC