Earlier quoted context omitted.
I see the proposals of binary protocols, push content, etc. as symptoms of a deeper issue. Different than the spirit of HTTP, those protocols have little to do with publishing content anymore. They are just more kludges, in the history of kludges, to patch browsers into application platforms. That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can…
Right. Because the alternative, bloated pages out the wazoo makes so much more sense than having smarter Apache and Nginx servers who will do all this for you. Remember, most of the web will be connected by cell phones, we need better protocols for that.
The 7-bit Internet
81–90 of 162 posts
Re: The 7-bit Internet
#82Earlier quoted context omitted.
I'm starting to feel like I start all my HN posts with "Hi, I'm a sysadmin." Hi, I'm a sysadmin. Sometimes we have to debug things that are on the other side of the world. When we do that, we need to have a mental model of what we're doing. You're familiar with that as a software developer: you have a mental model of the capabilities of the language that you are using, and you are fitting that in with the mental mode…
Hi, I'm a programmer. As a sysadmin, do you really have to deal with HTTP protocol by hand on such basis that a tool could not do the task for you if the protocol wasn't human readable?
I need to deal with a dozen protocols in an emergency situation where I can't guarantee the appropriate tool is going to be available. (When it's not an emergency, yay tools!)
For the same reason, I can use vi with no vim extensions. For the same reason, I like configuration files written in text formats, not binary blobs. Binary would be faster, sure. When it breaks, you need the precise tools to know what you're doing.
I commend to you RFC 3117 - http://www.rfc-editor.org/in-notes/rfc3117.txt - as a discussion on how to figure out what a network protocol has to do, and how.
Re: The 7-bit Internet
#83I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do: cake:~ mali$ telnet google.com 80 Trying 74.125.235.8... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 ....... HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 22:25:02 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 At which point they go "oh cool" and…
Re: The 7-bit Internet
#84This meme needs to die. It's like ending every post with "Just kidding, I don't know what I'm talking about, I'm just cargo-culting blog attention-desperate person trying to build my Klout score to impress myself."
Re: The 7-bit Internet
#85My personal "wow, it's just this?" moment came when, in high school, I figured out how to IRC from a Unix box that didn't have an IRC client installed, just by telnetting to the IRC server. The only particularly annoying part was that you'd get disconnected if you were idling and didn't respond to a PING with a PONG quickly enough. It was also a fun way to learn programming. mIRC at some point added a sockets interfa…
I think TAOUP sums up a few important points about text protocols [1] and why going binary is not always wise. Obviously the main drive here is money and I'm sure we all have stories where short term money translates later to large unforseen and/or hidden costs.
Bandwidth capacity is growing exponentially so do we really need this, even for the savings ?
I'd rather see people invent clever new ways to do wonders with text streams than go back to opaque and obscure data structures that bring back to me rememberances of old days proprietary protocols.
After all, if our fathers made the choice of text streams at a time when each byte cost much more than now, there may be good reasons.
[1] http://www.catb.org/esr/writings/taoup/html/ch05s01.html
Re: The 7-bit Internet
#86Earlier quoted context omitted.
I feel as though the people in this thread against (well-designed) binary protocols have never tried implementing a binary protocol. Length-prefixed fields and direct encoding of binary data go a long way to simplifying implementing a protocol. The ease of implementation of a simple binary protocol should not be underrated.
It's not just the binary. It's that HTTP 2 is hugely more complex. Excessive complexity is a general engineering smell. It can't be all that difficult to implement a protocol for applying a few verbs to URIs. Complex + non-discoverable = bad engineering
Re: The 7-bit Internet
#87Earlier quoted context omitted.
And billions of money wasted because browser vendors, at some point long ago, decided to accept invalid HTML.
and lots of experiments, new websites and happy users appeared because HTML has been accepted leniently
Those people would have figured out how to ship a web page; they'd just would have had so much trouble figuring out why one they shipped was't working, because the browser would have told them.
Re: The 7-bit Internet
#88Earlier quoted context omitted.
This has been on my mind, too, for a long time. Many applications don't fit the semantic framework of the WWW anyway; why not call it a day and fork it? This way the web app crowd will be able to do their somethingJS magic without worrying about what the WWW was meant to be, and the people who use WWW for publishing can get a sane platform back on track.
That would be a big win if you can pull it off. I wonder what is the best way to do it. convincing all owners of web apps to migrate to a new infrastructure strikes me as extremely hard. convincing the millions of 'publishers' of web writings (including all bloggers) to migrate sounds really hard, too.
Re: The 7-bit Internet
#89Oh sure, let's keep buffer bugs, waste tons of bandwidth and storage, burn millions of CPU hours in parsing computer-generated text, completely ban encryption and screw it for all non-en_US-speakers so that it could be debugged via misuse of a protocol from 1983 that no one sane uses.
I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence. You can talk about efficiency until you're blue in the face, but human-readability is very useful. I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant prog…
Re: The 7-bit Internet
#90I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do: cake:~ mali$ telnet google.com 80 Trying 74.125.235.8... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 ....... HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 22:25:02 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 At which point they go "oh cool" and…
You've never needed a basic TCP test without installing wget/nmap/etc? Most operating systems and hardware devices have telnet available for this kind of low-level troubleshooting. You've never needed to test an SMTP connection to see what the rejection message was on the remote server (when a user can't get you the bounced message you require)? You never wanted to see if an SSH port was open and what version was run…
Text protocols, on the other hand, require writing a parser, dealing with encoding back and forth between string representations and binary data, handling line delimiters, etc.
I'll take binary protocols any day of the week. Any cost they incur in not being human readable is offset by the value of them being so easy to implement.