Hacker News Reader

Comment by simfoo | Hacker News Reader

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.

View on HN

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.

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...

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/qu... [1]https://github.com/devsisters/libquic

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.

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.

Reply on news.ycombinator.com