Will there be something like "net/quic" in the future?

[ran...@gmail.com]

Hello people :D

I just want to pop up to ask whether or not there will be a builtin package that implements QUIC for Go.

As you may have already heard, the standardization for QUIC is almost done, many people are rushing to implement the protocol for their own product.

Since more and more people is expected to use QUIC in the future, it could be beneficial to include it as part of the Go standard package, as doing so not only could provide a way for server developers to implement QUIC servers/client with ease, but it could also help the net/http implement to their QUIC transport for both it's server and client.

So maybe consider it?

Thanks!

[Amnon]

You can try https://github.com/lucas-clemente/quic-go

You asked specifically about a builtin package i.e. a package in the standard library.
But I am not sure what advantages locating new protocols into the standard library 
would bring.

[Amnon]

Also worth watching the talk by the author 
https://www.youtube.com/watch?v=BvpRBdWwecU&ab_channel=dotconferences

[Axel Wagner]

I think part of that has been answered: It allows using it with net/http.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%40googlegroups.com.

[Amnon]

But quic-go can be used with net/http

Just call http3.ListenAndServeQUIC instead of http.ListenAndServeTLS
and all your handlers should just work.

QUIC is still evolving, and putting it inside the Go standard library means that 
it would be bound by the Go 1 compatibility promise, effectively freezing its behaviour.
Having it in the standard library would also tie it to Go's six-monthly release cycle,
(whereas quic-go seems to get released around once a month).

- amnon

[Axel Wagner]

On Thu, Oct 8, 2020 at 7:09 PM Amnon <amn...@gmail.com> wrote:

But quic-go can be used with net/http

Just call http3.ListenAndServeQUIC instead of http.ListenAndServeTLS
and all your handlers should just work.

That would mean you are *not* using `net/http`. In particular, it means code would need to explicitly import http3 to use it.

QUIC is still evolving, and putting it inside the Go standard library means that 
it would be bound by the Go 1 compatibility promise, effectively freezing its behaviour.
Having it in the standard library would also tie it to Go's six-monthly release cycle,
(whereas quic-go seems to get released around once a month).

OP wrote "as you may have already heard, the standardization for QUIC is almost done", implying this was a question about a future, stable spec for QUIC.

 

- amnon

On Thursday, 8 October 2020 at 17:56:09 UTC+1 axel.wa...@googlemail.com wrote:

I think part of that has been answered: It allows using it with net/http.

On Thu, Oct 8, 2020 at 6:37 PM Amnon <amn...@gmail.com> wrote:

You can try https://github.com/lucas-clemente/quic-go

You asked specifically about a builtin package i.e. a package in the standard library.
But I am not sure what advantages locating new protocols into the standard library 
would bring.

On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:

Hello people :D

I just want to pop up to ask whether or not there will be a builtin package that implements QUIC for Go.

As you may have already heard, the standardization for QUIC is almost done, many people are rushing to implement the protocol for their own product.

Since more and more people is expected to use QUIC in the future, it could be beneficial to include it as part of the Go standard package, as doing so not only could provide a way for server developers to implement QUIC servers/client with ease, but it could also help the net/http implement to their QUIC transport for both it's server and client.

So maybe consider it?

Thanks!

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/42e27b8d-58ee-4d1b-ae1d-069de7d65614n%40googlegroups.com.

[ran...@gmail.com]

On Friday, October 9, 2020 at 1:16:58 AM UTC+8 axel.wa... wrote:

OP wrote "as you may have already heard, the standardization for QUIC is almost done", implying this was a question about a future, stable spec for QUIC. 

Exactly. I was wondering whether or not Go will ship a QUIC package in the future when the standardization process is completed by people at IETF.

6 month release cycle is fine for a stabilized protocol, right?

[Amnon]

Since more and more people is expected to use QUIC in the future, it could be beneficial to include it as part of the Go standard package, as doing so not only could provide a way for server developers to implement QUIC servers/client with ease, but it could also help the net/http implement to their QUIC transport for both it's server and client.

I think it might be useful to spell out in more detail what way shipping it as part of the standard library would be beneficial.

There already is at least one way for client and server developers to use QUIC with ease
i.e. the  github.com/lucas-clemente/quic-go module.

It is also worth having a look at the Go FAQ's answer to 
Why isn't X in the standard library?

https://golang.org/doc/faq#x_in_std

[Axel Wagner]

On Sat, Oct 10, 2020 at 5:23 PM Amnon <amn...@gmail.com> wrote:

I think it might be useful to spell out in more detail what way shipping it as part of the standard library would be beneficial.

It could mean any Go program that uses `http.ListenAndServe` or similar could transparently (without any changes) start supporting QUIC, just as is currently the case for http2. I'm not even sure if it's the case or how that would look, given that QUIC is UDP based, but it's most certainly *not* possible without having some level of QUIC support in the stdlib - even if it's just imported privately, as http2 currently is.

I feel like that's pretty clearly spelled out.

There already is at least one way for client and server developers to use QUIC with ease
i.e. the  github.com/lucas-clemente/quic-go module.

It is also worth having a look at the Go FAQ's answer to 
Why isn't X in the standard library?

https://golang.org/doc/faq#x_in_std

On Friday, 9 October 2020 at 02:44:25 UTC+1 ran...@gmail.com wrote:

On Friday, October 9, 2020 at 1:16:58 AM UTC+8 axel.wa... wrote:

OP wrote "as you may have already heard, the standardization for QUIC is almost done", implying this was a question about a future, stable spec for QUIC. 

Exactly. I was wondering whether or not Go will ship a QUIC package in the future when the standardization process is completed by people at IETF.

6 month release cycle is fine for a stabilized protocol, right?

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/54edcad5-3512-42a4-8979-964194b1b0b5n%40googlegroups.com.