http://www.igvita.com/2011/04/07/life-beyond-http-11-googles-spdy/ tells us about Google's optimized HTTP-replacement running between the Chrome browser and Google's speed optimization proxy/cache servers.
The first paragraph criticizes latency issues with HTTP even after introduction of keep-alive and pipelining, so SPDY introduces session ids and a few other things that make it roughly equivalent to what PSYC provides.
In other words, all of these years PSYC would have been a better HTTP if anyone cared and had the power to change browser source codes. Why?
- PSYC allows fully bidirectional message passing at any time, never wait for anything
- Tags let you match up requests with replies. SPDY calls them session ids.
- PSYC has a compact mode which is like SPDY's compression.
SPDY doesn't just look like an anagram of PSYC, it also does almost the same things. The only major difference is the binary framing header, disallowing the use of text templates. A minor difference is the priority scheduling which hasn't been necessary in PSYC applications as yet, but is trivial to add for web-like applications on top of PSYC. Having the server push documents to the client even before the client knows it needs them is obviously trivial in PSYC, too.
Now that there is no terrific reason to use SPDY, a protocol designed to improve on HTTP, why not use a protocol that does the same job, but a lot of other jobs too? More and more I get the impression the IETF is fundamentally wrong to think every job needs its own protocol. We need at least some basic building blocks that do their job truly well and the Internet still has no decent basic protocol for messaging and document transfer.