Linked by mufasa on Mon 10th Aug 2009 12:25 UTC
Thread beginning with comment 377993
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Why would you not compress the binary format?
A typical HTML page contains almost entirely text. Not markup - text. Content. That wouldn't change just because you're using a binary format, that binary format would still contain large amounts of text.
The solution? Compress it!
Then you end up with a compressed text format, and a compressed binary format, which are about equal in size. Both are easily machine-readable. Only one is human-readable. Simply using a binary format is not going to make the tools magically better, so you're really not going to get any better tools than we have now.
Why would you not compress the binary format?
Of cause you can do that, if it makes sense.
A typical HTML page contains almost entirely text. Not markup - text. Content. That wouldn't change just because you're using a binary format, that binary format would still contain large amounts of text.
The solution? Compress it!
The solution? Compress it!
Well, HTML is somewhat okay for documents, which it was meant for. However, the markup is dominant in most dynamically generated HTML pages. I.e., this osnews editor page is 366 lines of markup, with very little content (the quote of your comment :-) ).
Then you end up with a compressed text format, and a compressed binary format, which are about equal in size. Both are easily machine-readable. Only one is human-readable. Simply using a binary format is not going to make the tools magically better, so you're really not going to get any better tools than we have now.
In the case of documents I agree. However, XML is missused for computer-to-computer communication and many HTML pages are mainly formating markup.
I don't talk about tools. I talk about performance and useability; Smaller server load and better responsiveness in the browser (client).
Edited 2009-08-11 02:51 UTC




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