3 ms·

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

by 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.
  - M2Ys4U 13y ago
    HTTP/2 doesn't prevent us from using lower-level protocols like QUIC, though. HTTP/2 over QUIC would work just as HTTP/2 over TCP

by pilif 13y ago

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.
- M2Ys4U 13y ago
  HTTP/2 doesn't prevent us from using lower-level protocols like QUIC, though. HTTP/2 over QUIC would work just as HTTP/2 over TCP