101–110 of 162 posts
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)
Earlier quoted context omitted.
The mind-bending complexity of the proposed HTTP 2.0 does very little to gain the little guy, or a young generation exploring the web: in fact it shuts them out. If the internet should have taught us one thing so far, it is that it's the open technologies which are built to be easy to understand and explore for humans which have driven the net forward. HTTP 2.0 is massive step backwards in that respect, and the only…
HTTP 2.0 is going to happen whether we complain about it here or not. While we can certainly wait and see whether people will balk and make changes, the only true way to stop it is to replace it. If you can write a better set of protocols that meet the requirements, do it. If you can't then work with or support those that will.
Earlier quoted context omitted.
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 protoco…
It sounds like your argument is a preference for a pre-written parser library over having to write the parser yourself. Yeah, sure, no one would disagree with that for day to day use. It's when you don't have the pre-written library available that a text-only protocol will save your day.
Slowing down everyone forever just to ease telnet debugging is a misdirected optimization.
I don't buy the "argument from visibility", for example.
HTTPS and DNS are both binary protocols and you need tools to parse them in order to get telnet-like visibility. Does that mean when it comes to those protocols "we are forced to rely on other tools to hide the underlying complexity and dumb things down to a point where they are manageable", as the author says?
I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.
The mind-bending complexity of the proposed HTTP 2.0 does very little to gain the little guy, or a young generation exploring the web: in fact it shuts them out. If the internet should have taught us one thing so far, it is that it's the open technologies which are built to be easy to understand and explore for humans which have driven the net forward. HTTP 2.0 is massive step backwards in that respect, and the only…
Yeah, but the speed of light isn't getting any faster, and little guys can't afford to have their servers everywhere. If HTTP 2.0 reduces the round trip count, then it will make a big difference in download times for small pages.
I work in telecom, and this makes me think of two protocols I work a lot with, SS7 and SIP. SIP is like HTTP, in fact I believe it was modelled after HTTP and has a lot in common with it. You can troubleshoot SIP issues very easily using a packet inspector like ngrep (using Telnet might be a bit difficult as there are some timers that expire if you don't respond fast enough, but that's besides the point). Then there'…
But if you're developing for a protocol with garbage documentation (or no documentation), a text based protocol at least offers some amount of intrinsic documentation.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
HTTP 2.0 is going to happen whether we complain about it here or not. While we can certainly wait and see whether people will balk and make changes, the only true way to stop it is to replace it. If you can write a better set of protocols that meet the requirements, do it. If you can't then work with or support those that will.
Like IPv6? Its taken more than 10 years to approach 1% traffic share. Perhaps HTTP 2.0 will happen but I wouldn't bet money on it being everywhere anytime soon.