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).
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).
> 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.
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.
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?
We can discuss alternatives to PNaCl, but that isn't really the issue. Even if you have something you believe has no peer at the moment, that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons.
Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.
> that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons.
What Google is doing with PNaCl is the standards process. Standards start life by being not-standards that someone shipped and enough people liked to make it into a standard.
There is nothing wrong here, nothing whatsoever. This is exactly how the process should work. Design-by-committee standards suck. Standards that won through raw competition? Those are all the good ones.
While I agree with you that competition is crucial, and without experimentation we will get nowhere, it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition".
Often things win not through fair competition. For example, WebSQL "won" on mobile because WebKit won on mobile, and WebKit happened to have WebSQL. If WebKit had had, say, the Audio Data API (which it did not), then the Audio Data API would have "won". Neither of those APIs won or would have won on its own merits, but because it was backed by the 800 pound gorilla in the space. (I chose Audio Data as an example because it is not in the same space as WebSQL, i.e. not competing with it, and was a nice API, that failed).
And the problem is that PNaCl will fragment the web, and already has. That's a serious problem - for everyone but Google.
> it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition".
It is worth noting that the findings in the antitrust actions in the US over Microsoft's illegal and anti-competitive behavior in establishing IE's dominance indicate that that claim is, at best, misleading.
I would argue the opposite, in fact - that it shows what happens with pure unrestrained competition. Which leads to monopolies and other forms of competition suppression, ironically, of course.
Regardless, we don't need to agree on that point. There are plenty of other examples in tech (and outside) of things winning through "raw competition" that are just not that good.
But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.
But isn't that exactly what happened with SPDY? They shipped it unilaterally first, then later on it got standardized as HTTP2.
SPDY initially began inside Google. But rather quickly it got enthusiastic interest from multiple outside parties, and a standardization process began. We can see the (successful) end of that process now. Yes, it's true that many standards begin that way.
PNaCl also began inside Google. Discussions regarding it, and the PPAPI on which it depends, were a combination of opposition (e.g. because PPAPI duplicates existing web APIs, and because it's a plugin API, which browsers are trying to move away from) to ignoring. Google continued to work on it, enabled it on the Chrome Web Store, and despite any change in the response of the community over a period of years, enabled it for web content. Over a year has passed since then, and it seems clear that (1) no browser outside Google thinks PNaCl is a good idea, and (2) no significant interest has been shown from non-browser vendors either (Google itself is the main user of PNaCl).
Also, to make things even worse, during all that time, PNaCl has not been brought to any standards body.
Another large difference is that, in practice, SPDY didn't pose a compatibility threat to the web. It has clear fallbacks so that content still works without browser support for it. And while it is possible bugs could still cause breakage, it didn't happen in practice. So moving forward somewhat quickly with SPDY was still arguably a responsible thing to do.
Whereas, PNaCl is already showing fragmentation problems, with several Google properties using PNaCl and consequently only working in Chrome.
There is therefore every reason for Google to disable PNaCl, because it is nonstandard and bad for the web to keep it on. Unless Google simply does not care about standardization here.
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.
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.
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.
