Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

81–90 of 162 posts

Re: The 7-bit Internet

#81

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.

Did you read the comment or just skimmed? I don't question the technical merits, but the underlying motivations, which I believe are fatally flawed.

Re: The 7-bit Internet

#82
post #61
post #42

Earlier 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?

No.

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

#83

I 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…

the cool kids use nc(1)

Re: The 7-bit Internet

#84
> You should follow me on Twitter.

This 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

#85
post #18

My 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 remember just about the same, some 15 years back. Discovering networks and being able to mess with them, even though my programming skills were still very basic. This is a good part of what made me enjoy programming. Exploring this world, feeling it within grasp.

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

#86

Earlier 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

HTTP is already painfully complex to implement correctly. It's also a terribly wasteful and poor engineered protocol for anything other than fetching documents.

Re: The 7-bit Internet

#87
post #44

Earlier 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

And we've wasted vast mountains of money dealing with the resulting brokenness of the web.

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

#88
post #32

Earlier 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.

What do you think 'native' platforms are? They're the platforms built to support app development.

Re: The 7-bit Internet

#89
post #22
post #12

Oh 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…

The problem with ASN.1 was ASN.1, BER, and DER themselves not the fact that a binary encoding was used.

Re: The 7-bit Internet

#90
post #57

I 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…

When its easier to write tools, tools are more plentiful. Same binary protocols make it an afternoon's work to implement most protocols, and even less time if all you want to do is open up a socket and send some EHLOs.

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.

Post reply on HN