go
go copied to clipboard
golang
x/net/websocket: remedy neglect; merge with gorilla websocket?
It is not well maintained, and essentially everyone uses https://github.com/gorilla/websocket.
This was raised as a concern in #17244: because it is in the x/net repository, people attach greater value to it than it really ought to have.
/cc @dsnet
EDIT 2016-12-02: Copying in my better-phrased problem statement from later in the thread:
The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.
Along the lines of #17244, there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.
We can't just delete something and break people who aren't vendoring it.
We can document that it's deprecated perhaps.
Or somebody could maintain it.
Deprecated might be fine, but my experience is that I (and other devs I've talked to) have wasted time trying to use the package only to find out it fails in production and that Gorilla's package works.
I support a strong deprecation message. Would that message endorse the Gorilla implementation?
If we implement golang/lint#238, I think that will help people avoid wasting time developing with deprecated packages or features.
"fails in production" -- what are the open bugs? There's not much to WebSockets. I'm afraid we're going to spend more time discussing things on this bug than we would just fixing any such issues.
Beyond any bugs that could be fixed by maintenance, the deeper problem with x/net/websocket is that it has the wrong API. It puts an io.Reader/Writer interface on top of what is fundamentally a message-based protocol.
I agree it should be documented as deprecated in favor of gorilla/websocket.
It's been long enough since I last tried to use it, but off-hand, you cannot implement a correct websocket reverse proxy with the current API, since it tries to implement io.Reader/io.Writer. Websocket, for better or for worse, is a frame-oriented protocol, not a stream-oriented protocol.
I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write.
I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net.
I suppose this all kinda depends on the policy for x/* we figure out in #17244.
I had this problem with a version of my profile package.
My solution was to move the code into a branch and deleting all the code from the package on master so it could not be imported. The README has told people not to use the package for years, now in addition jt says if they still want to do it anyway, they can find the code in the branch.
I considered replacing the paxkage with one that panic'd during init, but that felt like adding insult to injury.
On Fri, 2 Dec 2016, 08:59 Brad Fitzpatrick [email protected] wrote:
I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write.
I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net.
I suppose this all kinda depends on the policy for x/* we figure out in #17244 https://github.com/golang/go/issues/17244.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/18152#issuecomment-264322154, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA2pJ4SojprgRJRtypivu71yvE_H4ks5rD1FIgaJpZM4LB-47 .
Please do not deprecate it. At work, we are using golang.org/x/net/websocket exclusively and we have never had any problem with it*. Quite the opposite, in our use case it's more robust than what we've ever expected.
*: Of course, that says nothing whatsoever about any trouble anyone else might have with it.
No, not really. Deprecated is not black & white. We continue to fix bugs in other deprecated stuff when there's a good bug report and a clear fix and super minimal risk of breaking existing users. It just means we're not adding features to it, or means that a better way is known to exist.
Great news, honestly. But then again, why to mark it deprecated in the first place? We can cope with it getting no attention from people not loving it, but we do and if we run into a bug we need to resolve, we would be more than happy to contribute the fix.
Status quo anybody?
But then again, why to mark it deprecated in the first place?
To tell users they might be happier elsewhere.
Precisely to @bradfitz's point: Deleting may be too strong, but I want to send a strong signal that there's a much better maintenance story for gorilla/websocket. Effort spent on x/net/websocket may be better spent on gorilla/websocket.
To tell users they might be happier elsewhere.
I really really really don't want to sound snarky, but by that logic, the Go repository might be marked deprecated as well - just because users might be happier with Rust, C, Java, ...?
Effort spent on x/net/websocket may be better spent on gorilla/websocket.
I have no intention, nor desire to suggest or propose, regardless how impossible and foolish that would be, to delete github.com/gorilla/websocket, just because we don't and probably never would use it.
I really really really don't want to sound snarky,
Yet you did. And it's not very productive. It's actually just noise in this thread.
If you want to be productive, though, step up and maintain golang.org/x/net/websocket. That's one of the options I listed in my first comment (https://github.com/golang/go/issues/18152#issuecomment-264319615)
I apologize, @cznic. The current proposal process biases bug titles to be action-based (do X) versus focused on problem statement, so I should have described the problem instead of a proposed plan of action. Maybe this is something we should consider improving in the proposal process.
The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.
The other issue I see is along the lines of #17244, where there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.
And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.
It's actually just noise in this thread.
I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).
Nonetheless...
If you want to be productive, though, step up and maintain golang.org/x/net/websocket.
And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.
Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.
I apologize, @cznic. ...
@zombiezen Relly appreciated, but there's nothing to apologize for. I don't agree with the proposal, but that's nothing personal. If I made an impression otherwise then it's my duty to apologize for my fault - sorry.
PS: @all Getting the company's approval to use Go and/or code from golang.org/whatever is one thing. The same for code from other domains is not the same.
Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.
If you send us CLs, we'll +2 and you can submit. If others send you CLs, we'll give you access to +2 their CLs and you can submit.
I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).
I find your comparison between recommending a maintained package and recommending a whole alternate language not even remotely equivalent. They're pretty absurdly different. You also found it ridiculous, which is why you prefaced it with "I really really really don't want to sound snarky". You can't just say something outlandish and preface it with "Not to be $X or anything, but ....".
By the time most people are selecting a websocket package, they've already selected their programming language (Go, in this case). On the off chance they haven't yet selected their programming language (say, they're writing a prototype application to decide whether they like the Go ecosystem), that argues even more in favor of @zombiezen's point that we should point them to the solution that's going to be make them happy, rather than the first thing they stumbled into.
Hence https://golang.org/cl/33806
Thank you Brad,
Not to add noise to the issue, but we've recently had to introduce websockets to our app and had this debate do research to find out wether x/net/websocket would work. Luckily I was aware of discussion in https://github.com/golang/go/issues/17244 which mentions websocket vs the gorilla package. The mention will help others save time and avoid using something just because it looks official.
If others send you CLs, we'll give you access to +2 their CLs and you can submit.
Let's roll.
@leaxoy, no thanks. Unmaintained code in x/ is bad enough. We don't also want more code in std, especially if it's unmaintained. See https://golang.org/doc/faq#x_in_std
FWIW, the message in this package's godoc is not strong enough, one of my students ended up using it. You may want to consider a statement to the effect of "do not use this package, we'll murder a puppy if you do", or something. Please mention clearly what is the recommended replacement.
What about an init function which prints a message when any program links against it.
On Fri, 2 Dec 2016, 17:51 Juliusz Chroboczek [email protected] wrote:
FWIW, the message in this package's godoc is not strong enough, one of my students ended up using it. You may want to consider a statement to the effect of "do not use this package, we'll murder a puppy if you do", or something. Please mention clearly what is the recommended replacement.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/18152#issuecomment-264404055, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcAx1mYMIJxHJkUB9zfVkhdNB-RpvOks5rD9wmgaJpZM4LB-47 .
What about an init function which prints a message when any program links against it.
I think it's excessive. I think the main point I'm making is that there's a need for one (and just one) recommended replacement, so that people know what they should use without the need to evaluate a plethora of libraries.
So please put a clear statement "don't use this package, use X instead", and people will listen.
-- Juliusz