websocket
websocket copied to clipboard
gorilla
⚠️ New maintainers needed
I am stepping down as the maintainer of the gorilla/WebSocket project.
I am looking for a new maintainer for the project. The new maintainer should have a track record of successfully maintaining an open-source project and implementing RFCs.
Potential maintainers can gain the required experience by contributing to this project. I need help triaging issues, reviewing PRs, and fixing issues labeled "help wanted." If you are interested, jump in and start contributing.
If you rely on the quality and ongoing maintenance of this package, please get involved by helping to maintain this package or finding people to help maintain the project.
Hey guys,
I am very interested in helping maintain gorilla/websocket. I currently deal with a lot of networking in Golang and believe I could be of service to the project and team.
I'm also working on networking/sockets in Golang. Happy to help maintain/contribute ⚡️
Since people are constantly hammering on x/net/websocket as "unmaintained" and "everyone uses gorilla/websocket", please consider putting in more than a month's worth of half-baked effort to make sure you have found a suitable maintainer for this, since many production systems rely on its quality.
There’s no need for combative language here @binary132. This is an OSS project, primarily maintained by an individual.
If (commercial) production systems rely on this package, having those engineers dedicate time to contributing back or helping with triage would be a far more reasonable request vs. suggesting Gary put in more than a “half baked” effort here.
Finding maintainers & contributors is really hard. Most requests fall on deaf ears. I don’t blame Gary for putting a clear timeline around this.
@garyburd have you considered the idea of merging into the official exp. stdlib? Thus probably replacing the current websocket implementation?
Nevermjnd, i didnt read the previous comments. Still @garyburd opinion on this regard will be much appreciated!
@glerchundi I agree that the packages should be merged (by replacing the x/net/websocket package), but I do not have time to do the work and no one else has stepped up to do it. https://github.com/golang/go/issues/18152#issuecomment-332949233
Merging the packages does not help with this issue. There are no maintainers for the x/net/websocket package.
What's the status of this project? I'm looking to switch to gorilla/websocket for the control message pin/pong support in my project.
@prologic I'm thinking best course of action is to just contribute. If we need to make any updates/changes fork gorilla/websocket, do whatever is needed, then make a PR. The more people we have helping out the better :D
I stepped down as regular maintainer of this project. I will fix critical bugs during the search for a new maintainer.
If you rely on the quality and ongoing maintenance of this package, then please get involved by volunteering to maintain the package or by helping to find a maintainer. If you support any of the people who volunteered to maintain the project, then comment here or send email to the address on my GitHub profile.
@MiikeWilliams and @nynhex: Thank you for volunteering to help maintain the project. As noted in the issue, I want to see some consensus on the new maintainer. That has not happened yet.
@elithrar Thank you for your help with this project and your comment above.
This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: [email protected] W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd [email protected] wrote:
I stepped down as regular maintainer of this project. I will fix critical bugs during the search for a new maintainer.
If you rely on the quality and ongoing maintenance of this package, then please get involved by volunteering to maintain the package or by helping to find a maintainer. If you support any of the people who volunteered to maintain the project, then comment here or send email to the address on my GitHub profile.
@MiikeWilliams https://github.com/MiikeWilliams and @nynhex https://github.com/nynhex: Thank you for volunteering to help maintain the project. As noted in the issue, I want to see some consensus on the new maintainer. That has not happened yet.
@elithrar https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385720231, or mute the thread https://github.com/notifications/unsubscribe-auth/ABOv-kRN5QKBJaRMcJl7bJdtfLVieCrlks5tuJE4gaJpZM4TC8KQ .
@garyburd, @kisielk and myself can merge any critical bugs/patches (as Gary addressed, above), and myself & @kisielk can triage in the meantime. We're both pretty strapped for time (+ maintain the other Gorilla repos), so it'll likely be "critical bugs" only.
I don't know where Gary stands on this, but if you start contributing fixes, documentation & triaging issues for some period to establish capability & trust, it will help us understand when to dole out write privileges to the repo.
On Tue, May 1, 2018 at 9:54 AM James Mills [email protected] wrote:
This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: [email protected] W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd [email protected] wrote:
I stepped down as regular maintainer of this project. I will fix critical bugs during the search for a new maintainer.
If you rely on the quality and ongoing maintenance of this package, then please get involved by volunteering to maintain the package or by helping to find a maintainer. If you support any of the people who volunteered to maintain the project, then comment here or send email to the address on my GitHub profile.
@MiikeWilliams https://github.com/MiikeWilliams and @nynhex https://github.com/nynhex: Thank you for volunteering to help maintain the project. As noted in the issue, I want to see some consensus on the new maintainer. That has not happened yet.
@elithrar https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/gorilla/websocket/issues/370#issuecomment-385720231 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABOv-kRN5QKBJaRMcJl7bJdtfLVieCrlks5tuJE4gaJpZM4TC8KQ
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385722683, or mute the thread https://github.com/notifications/unsubscribe-auth/AABIcOzOwnYM1mqFslZVlGWOmdU7-_F-ks5tuJNNgaJpZM4TC8KQ .
Sounds reasonable
On Tue, May 1, 2018 at 10:02 Matt Silverlock [email protected] wrote:
@garyburd, @kisielk and myself can merge any critical bugs/patches (as Gary addressed, above), and myself & @kisielk can triage in the meantime. We're both pretty strapped for time (+ maintain the other Gorilla repos), so it'll likely be "critical bugs" only.
I don't know where Gary stands on this, but if you start contributing fixes, documentation & triaging issues for some period to establish capability & trust, it will help us understand when to dole out write privileges to the repo.
On Tue, May 1, 2018 at 9:54 AM James Mills [email protected] wrote:
This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: [email protected] W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd [email protected] wrote:
I stepped down as regular maintainer of this project. I will fix critical bugs during the search for a new maintainer.
If you rely on the quality and ongoing maintenance of this package, then please get involved by volunteering to maintain the package or by helping to find a maintainer. If you support any of the people who volunteered to maintain the project, then comment here or send email to the address on my GitHub profile.
@MiikeWilliams https://github.com/MiikeWilliams and @nynhex https://github.com/nynhex: Thank you for volunteering to help maintain the project. As noted in the issue, I want to see some consensus on the new maintainer. That has not happened yet.
@elithrar https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/gorilla/websocket/issues/370#issuecomment-385720231 , or mute the thread <
https://github.com/notifications/unsubscribe-auth/ABOv-kRN5QKBJaRMcJl7bJdtfLVieCrlks5tuJE4gaJpZM4TC8KQ
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/gorilla/websocket/issues/370#issuecomment-385722683 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AABIcOzOwnYM1mqFslZVlGWOmdU7-_F-ks5tuJNNgaJpZM4TC8KQ
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385724831, or mute the thread https://github.com/notifications/unsubscribe-auth/ABOv-kFg85-WN3J-sixaRdZB1Vehif5Kks5tuJUWgaJpZM4TC8KQ .
--
James Mills / prologic
E: [email protected] W: prologic.shortcircuit.net.au
The Gofrs organization would like to help maintain this project. We have filed a help request issue to discuss ways to possibly maintain this. You can also contact us on the Gophers Slack in the #gofrs channel.
@garyburd @elithrar @kisielk I think we in the Gofrs would like to help look after gorilla/websocket. Right now our GitHub org is at about 20 people, and I assume most of them likely won't contribute to every project we work on. So I'm only expecting a handful to want to contribute to gorilla/websocket, but it could be more.
How would y'all like to start down the path of having us look after this repo? My initial thought was to become an administrator on the organization, and to then manage an org team for The Gofrs based on who wants to contribute to the repo. This would allow us to manage membership without needing to take more of your time away from the other projects.
@theckman I am looking for one or more people with a track record implementing RFCs and maintaining a non-trivial open source project. Gofrs team members are welcome to gain this experience by contributing to this project. We need help triaging bugs and reviewing PRs. The current maintainers will handle admin only tasks for those helping out.
The Gorilla maintainers want the package to remain at github.com/gorilla/websocket. Users of the package should not need to update their code to get the maintained version of the package.
@garyburd that sounds like a great fit. I've experience not only implementing RFC-compliant software, but having to troubleshoot software that was not fully compliant and causing sporadic issues. It helps you appreciate the importance of maintaining an open source project with RFC compliance and stability being the top priorities. I know that similar experience exists within the rest of the Gofrs organization as well.
Building trust through triaging of issues, and raising of PRs, makes sense. I'll happily start putting more of my time in to looking at things at this repository, including refreshing myself on the codebase. I know that @itsjamie, and maybe @jadr2ddude, from Gofrs are explicitly interested in helping as well.
Where does this library stands at the moment? If additional functionality (not necessarily critical bug fix of some sort) is added, will it get reviewed and merged?
@garyburd @elithrar @kisielk
Additional functionality will be considered, but as per history:
• create an issue explaining who the feature is for • provide an example of the API you wish to change or introduce • be OK with alternate suggestions - such as writing an example using existing APIs - is a polite “no” - every new feature is both a new thing for a user to learn & maintenance burden on a very stretched group of maintainers 😉
Hope this helps clarify.
On Sun, Mar 24, 2019 at 7:48 AM Eran Yanay [email protected] wrote:
Where does this library stands at the moment? If additional functionality (not necessarily critical bug fix of some sort) is added, will it get reviewed and merged?
@garyburd https://github.com/garyburd @elithrar https://github.com/elithrar @kisielk https://github.com/kisielk
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-475966209, or mute the thread https://github.com/notifications/unsubscribe-auth/AABIcAJ1DJ3OS6MKSMSUX24vIz6kAmdtks5vZ5A0gaJpZM4TC8KQ .
Building trust through triaging of issues, and raising of PRs, makes sense. I'll happily start putting more of my time in to looking at things at this repository, including refreshing myself on the codebase. I know that @itsjamie, and maybe @jadr2ddude, from Gofrs are explicitly interested in helping as well.
Just a quick drive-by to say hello on this issue; we were discussing the status of this project in the Gofrs' slack and I wanted to add myself to the above list.
Posted again on https://groups.google.com/forum/#!topic/golang-nuts/9D2JuYsq5Lo
@IngCr3at1on - if you're still interested, let me know. We'd specifically be looking for folks to start triaging, reviewing & writing PRs, and I can provide some limited rights to help, before we consider a "commit bit" given the risk to the project & its users.
@elithrar I mean I'm happy to continue to review issues and pull requests; as you know I've been doing this anyway I can't say how much time I'll have to write anything though. I added the above note as a member of Gofrs because if anything I'd prefer a collective of maintainers anyway :joy:
@IngCr3at1on - that works for me. Let’s keep this as-is going forward.
(I also asked as we’re not triaging everything just yet, and wanted to confirm the engagement level)
@elithrar ah good point, I'd be happy to assist with triaging, gives me a reason to remember to open github.
I wrote and maintain https://github.com/nhooyr/websocket
I'd be happy to maintain this package as well, of course respecting the backwards compatibility. I have a significant amount of experience with WebSockets, writing idiomatic Go libraries and contributing to open source.
I would mostly only merge in bug fixes as this package already has a very large API surface for what it does and defer users to my library where possible as it's simpler to add features for given the minimal API and approach.
I've already added a comparison table at #543 making it clear gorilla/websocket is the battle tested mature library whereas mine is newer, less used but attempts to provide a better API.
@nhooyr hello, you are doing a great work with your library, keep it up! But I believe that at moment there are no real concerns for most of Websocket users to move from Gorilla Websocket to your library. This package solves most needs that Websocket applications require, has stable API and receives security fixes. It's not broken, it's well designed and performs well enough. I'd really want the development of this package to continue. Personally I like API of this package too - with ping/pong callbacks, explicit write and read deadlines etc. Having a good alternative is always great though and I hope that your package will continue to be developed. But again - this package is still wealthy and actual.
@nhooyr hello, you are doing a great work with your library, keep it up!
I appreciate that.
But I believe that at moment there are no real concerns for most of Websocket users to move from Gorilla Websocket to your library.
I disagree. See my response at https://github.com/gorilla/websocket/pull/543#issuecomment-536234499
To clarify, I don't consider gorilla/websocket broken or not valuable. I've made it clear in my comparison that gorilla/websocket is the mature and battle tested option and if that's what a user wants, then that's what they should use.
This package solves most needs that Websocket applications require, has stable API and receives security fixes. It's not broken, it's well designed and performs well enough. I'd really want the development of this package to continue.
I apologize, I didn't mean to suggest I wouldn't add any features to this package. I absolutely would, but I wouldn't want to duplicate features. E.g. if user's want WASM support, they ought to use my library instead as it's already been implemented there and was much simpler to implement than it would have been here (see #432). Otherwise I'm going to just end up duplicating effort in this library and mine.
Of course if there is significant demand for a feature in this library, I would implement it.
Personally I like API of this package too - with ping/pong callbacks, explicit write and read deadlines etc
It's not the worst API but I think many users would benefit from the API in nhooyr.io/websocket. Like I mentioned, gorilla/websocket is the best option for users who want a mature and stable library but for the features my library has and gorilla/websocket doesn't, I think it's better to defer users to my library instead of duplicating effort.
I think it's better to defer users to my library instead of duplicating effort.
The same could be said the other way. Further, “duplicate effort” isn’t always bad - competing implementations improve each other, and APIs can’t fit all use-cases or users.
I am more than happy for you to point out cases where users would have an easier time with your library - those cases will always exist. Same as React vs Vue, mux vs chi, etc.
Right now, I’ll continue to maintain this whilst we look for a longer-term, dedicated maintainer.
On Sat, Sep 28, 2019 at 5:07 PM Anmol Sethi [email protected] wrote:
@nhooyr https://github.com/nhooyr hello, you are doing a great work with your library, keep it up!
I appreciate that.
But I believe that at moment there are no real concerns for most of Websocket users to move from Gorilla Websocket to your library.
I disagree. See my response at #543 (comment) https://github.com/gorilla/websocket/pull/543#issuecomment-536234499
To clarify, I don't consider gorilla/websocket broken or not valuable. I've made it clear in my comparison that gorilla/websocket is the mature and battle tested option and if that's what a user wants, then that's what they should use.
This package solves most needs that Websocket applications require, has stable API and receives security fixes. It's not broken, it's well designed and performs well enough. I'd really want the development of this package to continue.
I apologize, I didn't mean to suggest I wouldn't add any features to this package. I absolutely would, but I wouldn't want to duplicate features. E.g. if user's want WASM support, they ought to use my library instead as it's already been implemented there. Otherwise I'm going to just end up duplicating effort in this library and mine.
Of course if there is significant demand for a feature in this library, I would implement it.
Personally I like API of this package too - with ping/pong callbacks, explicit write and read deadlines etc
It's not the worst API but I think most users would benefit from the API in nhooyr.io/websocket. Like I mentioned, gorilla/websocket is the best option for users who want a mature and stable library but for the features my library has and gorilla/websocket doesn't, I think it's better to defer users to my library instead of duplicating effort.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370?email_source=notifications&email_token=AAAEQ4AZJYFPHLQ55WX625LQL7WSTA5CNFSM4EYLYKIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73EV4A#issuecomment-536234736, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAEQ4DEQ5PEKV5AFGB43XLQL7WSTANCNFSM4EYLYKIA .
The same could be said the other way. Further, “duplicate effort” isn’t always bad - competing implementations improve each other, and APIs can’t fit all use-cases or users. I am more than happy for you to point out cases where users would have an easier time with your library - those cases will always exist. Same as React vs Vue, mux vs chi, etc.
I agree that is true in general, but I don't think it is in this case. The big benefits gorilla/websocket has are the obvious maturity, support for prepared messages, low level control, compression and configurable buffer sizes, for which I would continue to recommend gorilla/websocket.
However, excluding maturity, most people do not need these features.
- Prepared messages
- I have not added this yet as no one has ran into performance issues nor have I seen any benchmarks that this feature would improve performance significantly.
- Configurable buffer sizes
- Server side is blocked on https://github.com/golang/go/issues/13870
- I'll add client side support if benchmarks make it clear there is a significant performance difference. Most WebSocket messages are very small so I don't expect there to be a big performance improvement. If there is demand for it, this is trivial to add.
- Low level control
- My goal was to provide an API expressive enough to not require low level protocol control.
- For extremely unusual cases, I would still recommend gorilla/websocket or gobwas/ws
- Compression
- See https://github.com/nhooyr/websocket/issues/5#issuecomment-536238131 or #203
Thus, I don't see how gorilla/websocket could improve upon the nhooyr.io/websocket API/feature set and distinguish itself.
I feel it'd be unfortunate to reimplement the features nhooyr.io/websocket already has when I've already put so much time, effort and thought into it and also considering that no one has stepped up to implement these features in gorilla/websocket for well over a year now.