Related [1]:<p><pre><code> Wired: How has your thinking about design changed over the past decades?
Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled
programmers to “throw the first version away,” then build a second one.
By the 20th-anniversary edition, I realized that constant incremental
iteration is a far sounder approach. You build a quick prototype and
get it in front of users to see what they do with it. You will always
be surprised.
</code></pre>
[1] <a href="http://www.wired.com/2010/07/ff_fred_brooks/" rel="nofollow">http://www.wired.com/2010/07/ff_fred_brooks/</a>
I think this (<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0816.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...</a>) follow-up makes a valid point:<p>> <i>In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I don’t believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody else’s problem.</i><p>If we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past.<p>That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> <i>actual</i> application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.
I am so glad there is at least one prominent name advocating this line, because I feel like this quote from another IETF discussion is becoming more and more relevant:<p>> Is there an IETF process in place for "The work we're doing would harm the Internet so maybe we should stop?"
- <a href="http://www.ietf.org/mail-archive/web/trans/current/msg00238.html" rel="nofollow">http://www.ietf.org/mail-archive/web/trans/current/msg00238....</a><p>HTTP/2.0 has been rammed through much faster than is reasonable for the next revision of the bedrock of the web. It was always clearly a single-bid tender for ideas, with the call for proposals geared towards SPDY and the timeline too short for any reasonable possibility of a competitive idea to come up.<p>There has never been any good reason that SPDY could not co-evolve with HTTP as it had already been doing quite successfully. If it was truly the next-step it would have been clear soon enough. All jamming it through to HTTP/2.0 does is create a barrier for entry for similar co-evolved ideas to come about and compete on even footing.
There is another interesting thread about internet of things <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...</a><p>"So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should <i>not</i> have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others."<p><a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0604.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...</a><p>"First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many
of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."
Interesting response from the WG chair: <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0820.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...</a><p>An aside: I find it odd how HN users jump to agreement when a link to a single mailing-list message is posted, ignoring other discussion on the thread. I think it's because the UI makes it hard to see the rest of the conversation (unlike -say- the comments UI on HN itself)
To put the comment and its author in context, Poul-Henning Kamp is the main developer of Varnish, a widely used high-performance standard-compliant HTTP cache.<p>PHK has experience of HTTP both from the server point of view (the main job of Varnish is acting as a fast HTTP server) and from client point of view (Varnish acts as client to the slow upstream HTTP servers).<p>As a side note, he also refrained for years from adding TLS support to Varnish after his review of OpenSSL and SSL in general (see <a href="https://www.varnish-cache.org/docs/trunk/phk/ssl.html" rel="nofollow">https://www.varnish-cache.org/docs/trunk/phk/ssl.html</a> ).
A much better comment to link to would have the grandparent, by Greg Wilkins from Jetty, who gives a lot more substance and context to the debate: <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0807.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...</a><p>It does seem a little shocking that the WG chair is proposing last call while still there's serious discussion of things like dropping HPACK.
I think it makes sense to take the time to get it right. Every version of HTTP will effectively have to be supported by just about every server and client forever or otherwise the web will break.<p>An incredible aspect of the web is that Tim Berners-Lee's first website back at CERN still works in modern browsers. Same with things like basically the entire Geocities archive.<p>When it gets to core infrastructure like HTTP you can't just iterate quickly and expect the entire internet to constantly upgrade along with you.<p>What works for early stage lean startups won't work here.
What an awful way to try and get a point across. An aggressive tone and negative words baked into every other sentence, making the statements very loaded. There's probably a lot of missing context from viewing only this link, though.
I think that one of the best things about HTTP/1.0 (and to a lesser extent 1.1) is its simplicity. The reason, to me, that that simplicity is so vital is because it has fostered large amounts of innovation.
It should be noted that the sender of this e-mail is Poul-Henning Kamp, known among other things for another e-mail from back in the day (relatively speaking): <a href="http://bikeshed.com/" rel="nofollow">http://bikeshed.com/</a>
Would it be accurate to suggest that the rushing of Google's SPDY, as HTTP/2.0, through IETF standardisation is roughly equivalent to the situation a few years ago when Microsoft pushed Office Open XML through as an ECMA standard? Or is that just a huge mischaracterisation?
I'm in favor of dumping HTTP/S and using a faster and more secure (by default) Transport protocol altogether. Post Snowden revelations we should be focusing our energy on that, rather than continuing to hack around this old protocol to make it faster and more secure.
Well, SPDY might be a "prototype", but it's solving real problems <i>today</i> - I care less if it's perfect or not, if it solves <i>all problems</i> or not, as long as it's easy to implement, has a decent footprint, and offers significant improvements over HTTP/1.1. An imperfect working prototype is better than a perfect blueprint that materializes in distant future where problems and environment can differ greatly.
Sounds to me like the real problem is lack of IP addresses, and the best strategy would be to hold off on updating HTTP and work on IPv6 ubiquity first. I can see why Google went a different route, but we don't all have to follow.
Just like they admitted that XHTML 2 was a mistake and scraped it, I feel they should do the same with this nonsense.<p>Nothing about spdy or http2.0 sparks any sort of confidence with regard to proper robust protocol design, keeping things simple nor properly separating concerns.
You know what we need, we need to pick <i>one</i> of those people and give 'em <i>one</i> day to invent HTTP/2.0 and it'll be a better spec compared to letting them all "decide" together by nerd-fighting each other into eternity.<p>No standard is perfect, but the worst standard is no standard.<p>Make up your fucking mind already.