4 ms·

I've said it before and I'll say it again. If Google wants others to use QUIC they will have to stop pointing at their Chromium source tree and say "there it is

by simfoo 11y ago

I've said it before and I'll say it again. If Google wants others to use QUIC they will have to stop pointing at their Chromium source tree and say "there it is". Provide a standalone library that implements QUIC for the major platforms and compiles without having to install custom build environments and people/projects will start using it.

apendleton 11y ago
I don't think they really want other people to use it, at least right now. I think they want the latitude to be able to make backwards-incompatible changes and only have to worry about roll-out on their own servers and to their own client software.
- billyhoffman 11y ago
  Yes. This. It's the same model as SPDY. See a problem (HTTP1/x utilizing the network poorly). Implement a proprietary protocol from just your clients talking with your web properties. Work out kinks. Standardize as HTTP/2. I wonder what the HTTP/2 equivalent of QUIC will be. Interesting aside. As I typed that summary above. I couldn't help but think of Microsoft and how SPDY might still exists as a private "market leading feature" if Google sold server software...
convivialdingo 11y ago
And more to the point, it's a massive pain to track down all the outside header references to build a stand-along library. In all honesty, I gave up and iterated my own secure UDP protocol based on the excellent Micro Transport Protocol.
DonPellegrino 11y ago
This, I'd love to give it a try, but I'm not going to touch it until there's a Makefile and a minimal documentation. Until then, it feels like an engineering experiment, not a major company-backed project.
lttlrck 11y ago
There is a standalone test client & server [0] not quite a library but it looks manageable. And there is libquicc [1], though yes, it would be nice if this came from google. [0]http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/quic/ http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/qu... [1]https://github.com/devsisters/libquic https://github.com/devsisters/libquic

by simfoo 11y ago

apendleton 11y ago

I don't think they really want other people to use it, at least right now. I think they want the latitude to be able to make backwards-incompatible changes and only have to worry about roll-out on their own servers and to their own client software.

billyhoffman 11y ago
Yes. This. It's the same model as SPDY. See a problem (HTTP1/x utilizing the network poorly). Implement a proprietary protocol from just your clients talking with your web properties. Work out kinks. Standardize as HTTP/2. I wonder what the HTTP/2 equivalent of QUIC will be. Interesting aside. As I typed that summary above. I couldn't help but think of Microsoft and how SPDY might still exists as a private "market leading feature" if Google sold server software...

convivialdingo 11y ago

And more to the point, it's a massive pain to track down all the outside header references to build a stand-along library. In all honesty, I gave up and iterated my own secure UDP protocol based on the excellent Micro Transport Protocol.

DonPellegrino 11y ago

This, I'd love to give it a try, but I'm not going to touch it until there's a Makefile and a minimal documentation. Until then, it feels like an engineering experiment, not a major company-backed project.

lttlrck 11y ago

There is a standalone test client & server [0] not quite a library but it looks manageable. And there is libquicc [1], though yes, it would be nice if this came from google. [0]http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/quic/ http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/qu... [1]https://github.com/devsisters/libquic https://github.com/devsisters/libquic