One day maybe?
The picture will take up more screen real estate than the article, I think we're nearly there...
Google has decided to mothball its home-grown SPDY internet application-layer protocol in future versions of its Chrome browser, in favor of the Internet Engineering Taskforce's HTTP/2 spec. "Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it's time to say goodbye," Google …
Google's decision to kill SPDY in Chrome will go unnoticed by most users.
Which is as it should be
Both the web browser and the server must support the protocol for it to have any effect, and few web servers enabled it – Google being a notable exception, naturally.
Quite a lot of high-traffic sites use SPDY and credit to Google for doing enough work to get a serious debate about HTTP2 which hadn't been going anywhere.
Google's work on open source and within standards bodies is generally pretty good and in stark contrast to Apple or how Microsoft used to work.
I can't agree with you 100% on that...
Microsoft is the largest corporate contributor to the Linux Kernel (To increase compatibility with Hyper-V and other Microsoft products) and Apple sends quite a few code changes up-stream to NetBSD (OS X's underpinnings are based on NetBSD).
>> Microsoft is the largest corporate contributor to the Linux Kernel
Microsoft do not contribute the most to the Linux kernel, that is old news:
http://www.theregister.co.uk/2013/09/16/linux_foundation_kernel_report_2013/
http://lwn.net/SubscriberLink/631509/0ac9f129c7a76ecd/
It's not a replacement for HTTP per se. It's a transport that sits underneath HTTP. So HTTP 1.1 traffic will still flow, but over a SPDY link rather than vanilla TCP.
In this way, it can understand the HTTP traffic flowing over it and enhance it. For example, getting the multi connnections over a single TCP socket, which HTTP totally messed up with the aborted pipelining feature (all browsers switch that off, because it's broken).
Yeah, I use spdy on my own VPS, hosting Tiny-Tiny RSS. It was merely a matter of installing an extra apache package, and configuring apache to load it.
On very simple tests, I think it nearly halved page load time. Https became much, much faster than Http.
I'm just hoping the replacement is as simple to install and use.
the protocol bit of the URL
There is no "protocol bit of the URL". There's a scheme portion of the URL1, but it doesn't necessarily identify the concrete protocol used on the wire. It names the abstract protocol - the language, semantics, and requirements - that the user agent and server use for their control and data flows. That can become something else under the covers.
the 'http://' bit is a pattern for humans, not machines
That's not really correct either. It's for both. The user agent uses it to decide what kinds of request messages it will send to the server, and how to interpret the server's responses.
This happens with standard HTTP/1.1 as well. A user agent talking to a server for the first time doesn't know if that server supports HTTP/1.1, so it has to send a request that's compatible with HTTP/1.0 as well. Once each side knows the peer supports HTTP/1.1, they can use message formats that aren't supported in 1.0, such as the chunked transfer encoding for message bodies.
1Some would say "of the URI", but consensus on the W3C and IETF URI mailing lists seems to be moving toward dropping that acronym.
I read the SPDY spec a long time ago. It seemed to exist to make Google's ads and web bugs faster by reducing the cost of extremely large HTTP headers. Anyone who wants fast loading web pages has already fixed that with a plugin to block ads and tracking cookies, leaving very little for SPDY to do except add complexity. Some of the amazing performance claims out in the wild were actually a result of it bypassing broken keep-alive configurations.