5 ms·

What happens if someone built a service based on it? Should they never trust browsers keeping alive even the shitty (in comparison to free and standardised HTTP

by fdsary 12y ago

What happens if someone built a service based on it? Should they never trust browsers keeping alive even the shitty (in comparison to free and standardised HTTP/2) features? What's great about the web is that now 20 year old services still are working in the latest runtimes (browsers).

quonn 12y ago
The server should fall back to HTTP anyway, so this should not be a problem.
azakai 12y ago
It is always risky to build a service based on something that is not yet standardized. SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. It would be the right thing for Google to remove SPDY at this point, otherwise it would be running a nonstandard protocol that other browsers do not, which can lead to fragmentation - as we saw just recently with an API that sadly Google has not removed despite it being nonstandard (FileSystem in the WhatsApp "Web" app). edit: To clarify, I mean what Google is doing with SPDY sounds like the right thing. I don't mean it should remove it right now, I meant it was the right thing to do, right now, to announce it would be removed after a reasonable delay (and 1 year sounds reasonable).
- dragonwriter 12y ago
  > SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. The "progress to be standardized" for SPDY was SPDY being chosen as the basis for HTTP/2; as I understand for a while SPDY has been being updated in parallel to the HTTP/2 development work to continue to reflect the state of HTTP/2 + new things the Google SPDY team wants to get into the standard, but its been clear for a long time that the intent was that SPDY as a separate protocol would be unnecessary once HTTP/2 was ready for use.
- kozhevnikov 12y ago
  To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
  - azakai 12y ago
    Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
    - pcwalton 12y ago
      Not to mention not removing H.264 after promising to do so.
      - azakai 12y ago
        Thanks, right, I forgot that one.
    - hammerandtongs 12y ago
      websql is so much nicer then the key/val firefox insisted on :(
      - thristian 12y ago
        WebSQL is nicer to use, but requiring every browser to be bug-for-bug compatible with SQLite 3.0.17 (or whatever it was) forever and ever is not nice for browser developers.
    - kllrnohj 12y ago
      > PNaCl is still enabled Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
- andrewd18 12y ago
  > It would be the right thing for Google to remove SPDY at this point It's going away, just maybe not soon enough for everyone's tastes. From the blog: > We plan to remove support for SPDY in early 2016
  - azakai 12y ago
    I think that's a reasonable timeline, actually - sorry if what I wrote was confusing to imply "right now". I meant to say "It would be the right thing for Google to announce the timeline to remove SPDY at this point in time." A year head's up gives people plenty of time to update their sites, and sounds fair and reasonable.
Dylan16807 12y ago
Nothing is being lost with regards to SPDY. Old versions were never supported; if you wanted to use SPDY you had to commit to keeping the server updated. So effectively they have just announced a long term support edition of SPDY. What an odd time to complain about the lack of long term support.

by fdsary 12y ago

quonn 12y ago

The server should fall back to HTTP anyway, so this should not be a problem.

azakai 12y ago

It is always risky to build a service based on something that is not yet standardized. SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. It would be the right thing for Google to remove SPDY at this point, otherwise it would be running a nonstandard protocol that other browsers do not, which can lead to fragmentation - as we saw just recently with an API that sadly Google has not removed despite it being nonstandard (FileSystem in the WhatsApp "Web" app). edit: To clarify, I mean what Google is doing with SPDY sounds like the right thing. I don't mean it should remove it right now, I meant it was the right thing to do, right now, to announce it would be removed after a reasonable delay (and 1 year sounds reasonable).

dragonwriter 12y ago
> SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. The "progress to be standardized" for SPDY was SPDY being chosen as the basis for HTTP/2; as I understand for a while SPDY has been being updated in parallel to the HTTP/2 development work to continue to reflect the state of HTTP/2 + new things the Google SPDY team wants to get into the standard, but its been clear for a long time that the intent was that SPDY as a separate protocol would be unnecessary once HTTP/2 was ready for use.
kozhevnikov 12y ago
To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
- azakai 12y ago
  Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
  - pcwalton 12y ago
    Not to mention not removing H.264 after promising to do so.
    - azakai 12y ago
      Thanks, right, I forgot that one.
  - hammerandtongs 12y ago
    websql is so much nicer then the key/val firefox insisted on :(
    - thristian 12y ago
      WebSQL is nicer to use, but requiring every browser to be bug-for-bug compatible with SQLite 3.0.17 (or whatever it was) forever and ever is not nice for browser developers.
  - kllrnohj 12y ago
    > PNaCl is still enabled Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
andrewd18 12y ago
> It would be the right thing for Google to remove SPDY at this point It's going away, just maybe not soon enough for everyone's tastes. From the blog: > We plan to remove support for SPDY in early 2016
- azakai 12y ago
  I think that's a reasonable timeline, actually - sorry if what I wrote was confusing to imply "right now". I meant to say "It would be the right thing for Google to announce the timeline to remove SPDY at this point in time." A year head's up gives people plenty of time to update their sites, and sounds fair and reasonable.

Dylan16807 12y ago

Nothing is being lost with regards to SPDY. Old versions were never supported; if you wanted to use SPDY you had to commit to keeping the server updated. So effectively they have just announced a long term support edition of SPDY. What an odd time to complain about the lack of long term support.