3 ms·

Trace those RFCs all the way back. Where does the format originate? Nearly 50 years ago, as a codification of what humans were writing by hand. Those formats m

Trace those RFCs all the way back. Where does the format originate? Nearly 50 years ago, as a codification of what humans were writing by hand. Those formats make tons of sense where you are encoding messages by hand. Be flexible. Allow comments. Allow continuing headers across multiple lines then turning the extra spaces into one. All this is great when ed (or nothing?) was your mail client. It makes absolutely zero sense in any protocol of the last 30 years at least. Code reuse for parsing a line? No one does that, and supposedly it's so easy they wouldn't need too, right? And it wouldn't work anyways, as different headers have different rules - you can't treat it just as a sequence of name-value pairs. Extensibility has nothing to do with text vs binary. And my complaint is bad text formats. Having strict, simple, rules, then using ASCII printable chars is just inefficient, but not atrocious. HTML is funny example, being the poster child of crap-interop, with browsers interpreting things differently, even at a basic level (unclosed tags, incorrectly closed tags, spacing, etc.). Can you explain how text is more extensible? Seems like that's totally dependent on the spec.

chubot 11y ago
Well, I'm not arguing that they are optimal now, or that code reuse is an issue now. My point is that it really couldn't have been any other way, for economic and evolutionary reasons. In your posts, I see the implicit assumption that "someone made a mistake a long time ago", and that a lack of knowledge by those people led to the current situation. I should have been more precise about extensibility. (I have had this argument a bunch of times...) Another way to say it is that text formats are more amenable to partial implementation. That's the "dual". Suppose you have N people using a protocol, and there are O(N^2) communication paths. And then three of those people have a need for some extension -- say they want to add some new caching mechanism to save bandwidth. They can negotiate an extension to the protocol out of band. If it introduces some value, then it might be adopted by everybody. Or it might just die. But at all points in time, somebody is extending. And they don't necessarily consult a spec to do so; they just read the raw messages and negotiate something based on their needs, which doesn't break other people. "The Art of Unix Programming" has more concrete examples of this process actually happening [1]. Depending on how you look at it, other users now have a partial implementation. It can also start the other way -- there are plenty of partial implementations of HTTP that are useful -- implementing only GET, not implementing caching, etc. Yes these are sloppy, but they are useful, and help the protocol gain adoption. Don't underestimate the number of people debugging HTTP with telnet or netcat in a shell script either. You can either try to each everyone the "right way" to do things or accept that there is a lot more diversity in the computing world that most people think. The precise things that make text formats a pain to deal with are the things that make them survive. There is no instant at which a global truth for the protocol is born; it arises over time. This wisdom is baked into the name: "RFC". It's open-ended and ambiguous. [1] http://www.catb.org/esr/writings/taoup/html/ch05s01.html http://www.catb.org/esr/writings/taoup/html/ch05s01.html

chubot 11y ago

Well, I'm not arguing that they are optimal now, or that code reuse is an issue now. My point is that it really couldn't have been any other way, for economic and evolutionary reasons. In your posts, I see the implicit assumption that "someone made a mistake a long time ago", and that a lack of knowledge by those people led to the current situation. I should have been more precise about extensibility. (I have had this argument a bunch of times...) Another way to say it is that text formats are more amenable to partial implementation. That's the "dual". Suppose you have N people using a protocol, and there are O(N^2) communication paths. And then three of those people have a need for some extension -- say they want to add some new caching mechanism to save bandwidth. They can negotiate an extension to the protocol out of band. If it introduces some value, then it might be adopted by everybody. Or it might just die. But at all points in time, somebody is extending. And they don't necessarily consult a spec to do so; they just read the raw messages and negotiate something based on their needs, which doesn't break other people. "The Art of Unix Programming" has more concrete examples of this process actually happening [1]. Depending on how you look at it, other users now have a partial implementation. It can also start the other way -- there are plenty of partial implementations of HTTP that are useful -- implementing only GET, not implementing caching, etc. Yes these are sloppy, but they are useful, and help the protocol gain adoption. Don't underestimate the number of people debugging HTTP with telnet or netcat in a shell script either. You can either try to each everyone the "right way" to do things or accept that there is a lot more diversity in the computing world that most people think. The precise things that make text formats a pain to deal with are the things that make them survive. There is no instant at which a global truth for the protocol is born; it arises over time. This wisdom is baked into the name: "RFC". It's open-ended and ambiguous. [1] http://www.catb.org/esr/writings/taoup/html/ch05s01.html http://www.catb.org/esr/writings/taoup/html/ch05s01.html