x/net/websocket: remedy neglect; merge with gorilla websocket?

[zombiezen]

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.

[bradfitz]

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.

[zombiezen]

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.

[dsnet]

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.

[bradfitz]

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

[cespare]

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.

[zombiezen]

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.

[bradfitz]

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.

[davecheney]

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 ***@***.***> 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 <#17244>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18152 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA2pJ4SojprgRJRtypivu71yvE_H4ks5rD1FIgaJpZM4LB-47> .

[cznic]

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.

[bradfitz]

@cznic, "deprecate" does not mean "delete".

[cznic]

Yep. But I guess it means "no more bug fixes for you, ever".

[bradfitz]

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.

[cznic]

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?