“SPDY does not clearly outperform HTTP over cellular networks” [pdf]
conferences.sigcomm.org
“SPDY does not clearly outperform HTTP over cellular networks” [pdf]
1–10 of 66 posts
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#2I think QUIC is supposed to address this:
http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#3I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#4I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#5I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
One, among many, of Microsoft's 1990's extensions was XMLHttpRequest. Fortunately, although it was (initially) vendor-specific, neither XMLHttpRequest nor SPDY is/was “proprietary” in the IP sense of the term.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#6I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#7I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
The difference is that Google has actually submitted SPDY as a possible basis for HTTP/2.0.
Too bad that it looks like it's going to be accepted, but that's a different issue alltogether (yeah. I don't like where HTTP/2.0 is going, but I can only "blame" the IETF, not Google).
Microsoft back then had no intention of submitting their changes to any standards body and was actually using patents and copyrights to ensure that it was difficult to impossible to reimplement their changes.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#8Earlier quoted context omitted.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
It's a new protocol, what do you expect? Tooling will improve over time.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#9Earlier quoted context omitted.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
First of all, SPDY is a properly documented protocol -- there are far more "open" protocols that are documented far worse. It's inside Google's interests to make SPDY adoption as widespread as possible, so it makes sense they would properly document it.
The other part of your argument is based on the fact that it's a binary protocol which makes it less intuitive and impossible/hard to debug when something goes wrong. This is indeed a trade-off chosen by SPDY that makes sense for a lot of the use cases: you're optimizing the protocol for computer, not for humans. You'll need additional debugging tools to find out what's wrong in exchange for better performance.
Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]
#10It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP.
It's Google who is promoting it and all the "hip" hackers will rally for its cause.