4 ms·

I 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 'standar

I 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.

StavrosK 13y ago
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
- blueskin_ 13y ago
  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.
  - ch0wn 13y ago
    It's a new protocol, what do you expect? Tooling will improve over time.
    - d0ugie 13y ago
      > It's a new protocol, what do you expect? It's in use in significant capacities on the most-tracked websites with impressive results you are welcome to easily see for yourself firsthand on your own server. More browsers than Chrome support it. More than one popular server supports it, with Nginx bundling it. CDNs are getting on board. Etc. This is the first somewhat-negative article I've run into about it. That Google keeps working on it and releasing new drafts rather than kicking back and leaving it alone for the sake of creating an appearance of maturity, tabling better ideas they come up with for later, I don't think is a sign of lack of maturation, rather a sign that the demand for SPDY and improved performance is strong because people are finding out it's helpful and that Google can be relied upon further to make the web faster.
  - stingraycharles 13y ago
    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.
  - deleted 13y ago
    [deleted]
  - youngtaff 13y ago
    I'd suggest that too many developers don't understand what goes on over the wire anyway. It's a documented binary protocol, is open and reasonably easy to understand - spdyshark will help.
osteele 13y ago
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.
pilif 13y ago
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.
- ajacksified 13y ago
  What don't you like about where HTTP/2.0 is going?
  - stormbrew 13y ago
    Can't speak for the person you're responding to, but personally, I don't think it makes sense for a semantically-similar but different in wire characteristics protocol to be called http/2.0. Nor do I think spdy has been around anywhere near long enough, nor been adopted organically enough, to justify being rammed through a process that seems to have been started almost specifically to get it that moniker (the call for proposals for the starting point was for less than a year, with only one possibility deployed at all, it was a foregone conclusion). The whole process had the feel of a sham. SPDY should have evolved as its own protocol, continuing under the spdy name, and http/2.0 should have simply evolved to a semantically-driven protocol with standard negotiation mechanisms for choosing the wire protocol (which could be the MIMEish thing we have now or SPDY). This would have been a good way to ensure the web has a solid upgrade path.
  - rektide 13y ago
    It doesn't define high level semantics other such as QUIC can use or build from. It's the whole kit and caboodle when it should have been broken up into clean modular pieces: framing layers, protocol layers, semantic layers. QUIC or other hopefuls trying to break from the mobile-horror-show that is TCP are left with nothing to start from, and HTTP/2 docs devolve into a commingled big-ball-of-mud as it hops from low level aspects to higher level aspects.
matthewmacleod 13y ago
I really don't see the point of stuff like SPDY and WEBP/WEBM. The former is generally more performant that HTTP, and the latter also offer benefits versus other options. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things. This is dangerously wrong, for two reasons: 1. These are open standards. They're not proprietary. 2. What is "improving things" if not proposing open, alternative standards which solve existing problems?
- est 13y ago
  you know what else offered more benifits? WMA over MP3, WMV over AVI.
  - BitMastro 13y ago
    And both are proprietary.. moreover you're mixing formats and containers
salient 13y ago
No, that's not at all like that. First off, they are proposing them to actually be standards, not just proprietary extensions that no one else can use, like Microsoft was doing. Second, WebM is actually open source, not proprietary.

StavrosK 13y ago

Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?

blueskin_ 13y ago
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.
- ch0wn 13y ago
  It's a new protocol, what do you expect? Tooling will improve over time.
  - d0ugie 13y ago
    > It's a new protocol, what do you expect? It's in use in significant capacities on the most-tracked websites with impressive results you are welcome to easily see for yourself firsthand on your own server. More browsers than Chrome support it. More than one popular server supports it, with Nginx bundling it. CDNs are getting on board. Etc. This is the first somewhat-negative article I've run into about it. That Google keeps working on it and releasing new drafts rather than kicking back and leaving it alone for the sake of creating an appearance of maturity, tabling better ideas they come up with for later, I don't think is a sign of lack of maturation, rather a sign that the demand for SPDY and improved performance is strong because people are finding out it's helpful and that Google can be relied upon further to make the web faster.
- stingraycharles 13y ago
  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.
- deleted 13y ago
  [deleted]
- youngtaff 13y ago
  I'd suggest that too many developers don't understand what goes on over the wire anyway. It's a documented binary protocol, is open and reasonably easy to understand - spdyshark will help.

osteele 13y ago

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.

pilif 13y ago

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.

ajacksified 13y ago
What don't you like about where HTTP/2.0 is going?
- stormbrew 13y ago
  Can't speak for the person you're responding to, but personally, I don't think it makes sense for a semantically-similar but different in wire characteristics protocol to be called http/2.0. Nor do I think spdy has been around anywhere near long enough, nor been adopted organically enough, to justify being rammed through a process that seems to have been started almost specifically to get it that moniker (the call for proposals for the starting point was for less than a year, with only one possibility deployed at all, it was a foregone conclusion). The whole process had the feel of a sham. SPDY should have evolved as its own protocol, continuing under the spdy name, and http/2.0 should have simply evolved to a semantically-driven protocol with standard negotiation mechanisms for choosing the wire protocol (which could be the MIMEish thing we have now or SPDY). This would have been a good way to ensure the web has a solid upgrade path.
- rektide 13y ago
  It doesn't define high level semantics other such as QUIC can use or build from. It's the whole kit and caboodle when it should have been broken up into clean modular pieces: framing layers, protocol layers, semantic layers. QUIC or other hopefuls trying to break from the mobile-horror-show that is TCP are left with nothing to start from, and HTTP/2 docs devolve into a commingled big-ball-of-mud as it hops from low level aspects to higher level aspects.

matthewmacleod 13y ago

I really don't see the point of stuff like SPDY and WEBP/WEBM. The former is generally more performant that HTTP, and the latter also offer benefits versus other options. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things. This is dangerously wrong, for two reasons: 1. These are open standards. They're not proprietary. 2. What is "improving things" if not proposing open, alternative standards which solve existing problems?

est 13y ago
you know what else offered more benifits? WMA over MP3, WMV over AVI.
- BitMastro 13y ago
  And both are proprietary.. moreover you're mixing formats and containers

salient 13y ago

No, that's not at all like that. First off, they are proposing them to actually be standards, not just proprietary extensions that no one else can use, like Microsoft was doing. Second, WebM is actually open source, not proprietary.