The 7-bit Internet

This is all very interesting...

I feel that the document-centric request-oriented nature of the web has been a powerful influence on the design of "web applications." But we still haven't really figured out how to do it.

The web has been full of applications since the beginning, no? There was no golden age of pure document sharing. So much of the web throughout its history has been CGI, ASP, JSP, ad hoc setups to provide dynamic sites. Session cookies, inscrutable URLs, forms with two dozen hidden fields encoding cryptic parameters...

(Here's a www-talk thread from 1993 discussing the new script support in NCSA httpd http://1997.webhistory.org/www.lists/www-talk.1993q4/0485.ht...)

But since the formulation of the REST architecture, it seems that more and more people are interested in what the WWW was meant to be. Maybe we're only beginning to understand the possible implications of the WWW design, and to purify that into a powerful conceptual framework.

Does that essentially involve a text-based HTTP protocol? I don't think that's the most important part.

The REST philosophy seems to say that the sane platform of the web is more crucially about clearly defined paths to typed resources providing a uniform set of actions and discoverable associations. This is not just for publishing -- what makes it so interesting and fruitful is the way it can be used to structure many kinds of applications in the form of published resources...

"Calling it a day and forking it" seems in some way to mean giving up on this fruitful encounter between two paradigms. Then you get a binary socket protocol with no resource structure but with a lot of potential for shiny stuff, versus a document-centric protocol that's slower and more restricted... And then all the big players do the shiny thing, and the document protocol is left for enthusiastic hobbyists and legacy applications...

IMAP is the protocol I love to hate with a burning passion... I get that it is enormously flexible. But it is also a total, utter nightmare to work with, for not very good reasons.

Though I don't really agree with you that you need a binary format for interop and performance. You'd get the same benefits if people just constrained the text protocols. E.g. Your performance "hack" for HTTP request methods is only a hack because method names can be variable length. We could constrain method names to 4 bytes and make the whole thing cleaner while still getting the text protocol benefits of being able to manually inspect request/responses. Similarly, picking a sane date format like iso-8601 and restricting it further to a specific set of options would do wonders while still being readable/writable for humans.

I do agree with you that once a protocol gets as widespread as HTTP most of the benefit is lost as we get better tools to use anyway, though. Especially with debug tools built into most browsers these days.

The issue is not that non-text protocols are impossible to analyse, but that each new non-text protocol requires new tools to do so. For IP, UDP and TCP we've had decades to create good tools. If a common binary serialisation format was agreed and most protocols stuck to that, it would be much less of a big deal to ditch text-only protocols and rely on client side tools to allow reading or manipulating them as text.

The tools might get written. But they won't be installed on those routers, remote servers you're not getting to install stuff on and all kinds of other places where people who work with networks frequently want to be able to talk protocols from.

It's largely irrelevant to me if there are tools out the wazoo to work with some binary protocol if I'm unable to run that tool everywhere.

And there's a huge range between advocating arbitrarily complex and flexible text protocols vs. binary protocols. You can "easily" do text protocols that are picky about field lengths and that use formats that can be parsed much faster than the more complex protocols.

If your protocol is using a small enough, regular enough grammar, it'd also be fairly trivial to allow a binary serialisation of requests or responses as an option without much extra overhead. E.g. start client connections with a word indicating it wants to "switch on" binary and length prefix any variable length fields instead of relying on an end of field marker, for example. (Or make human clients type out a word to switch to the text serialisation).

But very few protocols are so affected by latency in request/response exchanges that binary vs. text is a huge deal. For HTTP moving to a pure binary protocol might make sense because of how heavily we depend on it. But most protocols are not HTTP.

Under what circumstances are you logging into machines with only telnet available? Presumably you also lack SSH, otherwise you could use a tunnel, so I assume you're physically logging into a bare-bones OS that lacks even basic functionality. Is that really something you do often? And if so, why?

I love these discussions about text vs. binary protocols. I especially love the part where people defend binary protocols because they are more "efficient" and don't eat as much bandwith or processing resources.

May I remind these nice people that most text-based protocols we rely on today were designed in a time when CPUs were orders of magnitude slower and modems ran at 2400 baud? Talk about processing and bandwidth resources...

The resources consumed by having to interpret a text-based protocol pale in comparison with the resources consumed by all the levels of abstraction that modern frameworks/language runtimes that we use today. But wait, these save developer time, so they are a good thing. So does having protocols that can be troubleshooted by a human with minimal tools.