*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 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+unsubscr...@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.
