3 ms·
That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to b
by kijin 8y ago
That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.
- lclarkmichalek 8y agoMuch easier to update an app and its HTTP library than mobile device kernels. Particularly given how a large proportion of mobile devices are unsupported and won't get kernel upgrades any more.
- michaelt 8y agoThe thing is, there are two possible extremes: 1. Our design is complete, error-free and designed to stand the tests of time. It will be in common use, largely unchanged, in 40 years time. The TCP of the 2010s. There is widespread industry support. We want to move to the application layer to ease the initial roll-out. 2. Our design will need to change every few years, even we authors don't think it's finished. This is a Google-only project and most vendors are refusing to support it as they think it's badly designed crap. The ActiveX of the 2010s. We want to move to the application layer so we can force it through without anyone else's support. Where are we on the spectrum between those two options? I don't know.
- chrisweekly 8y agoGreat question!
- cdmckay 8y agoAn app can control which HTTP library it’s using and even bypass the built in one on the mobile device. That’s not possible in the case of TCP. So no, it’s not the same. Another issue they mention in the article is middleboxes, which basically will never be upgraded, and will never support new TCP features.
- josteink 8y agoNor will they support new HTTP-features.