Open rstoyanchev opened 8 years ago
if some people are still interested, I'm forking this project to keep it alive. I already have a good unpublished base code, full ES6 rewrite, dist file UMD, ready for npm, pending PR integrated, compatible utf-8 string and binary arraybuffer (solely with last rmq web stomp native websocket).
I'm only waiting for @jmesnil response due to the APL2.0 license (I do not exactly know what are the condition for a fork outside MIT license).
If some people are interest I'll need help to port the tests and the doc to a modern stack.
sounds good to me, thanks for taking it on!
+1 @JSteunou
I'm very interested too, I'll test it with my codebase if you'll publish it. Which license do you plan to use?
This project is under apl2 so I think I have to keep it. If some expert can enlight me about this I m all hear Le 28 mars 2016 6:39 PM, "Alessandro Polverini" notifications@github.com a écrit :
+1 @JSteunou https://github.com/JSteunou
I'm very interested too, I'll test it with my codebase if you'll publish it. Which license do you plan to use?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jmesnil/stomp-websocket/issues/121#issuecomment-202476525
@JSteunou Thanks for creating this fork. I no longer have time to maintain this project but I am very happy that you volunteered to do so. I am not a lawyer but as far as I am concerned, you only need to include the original copyright and license file (according to https://tldrlegal.com/license/apache-license-2.0-(apache-2.0))
Once you have published your fork and the new docs, I'll add a link from http://jmesnil.net/stomp-websocket/doc/ to your doc to make sure users will know about the latest code.
Here we go https://github.com/JSteunou/webstomp-client
Still a lot to do regarding tests and doc, any help is welcome.
Maybe you should create an organisation and continue development within that. It makes it easy to add owners and/or maintainers/developers in the future and would provide for a immutable url even if maintainer changes would take place in the future.
Instead of creating an organisation I would rather join an existing one like https://github.com/stomp
@jmesnil, I'm sure I speak for many in thanking you for this project! I completely respect your reasons for stepping away and as a father I understand your dilemma :) I do hope this project finds a home.
In the mean time I wonder if there isn't some relative hands-off way and a middle ground that would give this project some extra mileage? As you wrote the library is small, quite stable and documented but there will always be issues with browser compatibility. It seems rather feasible for the community to identify fixes in some cases but having a preferred place to contribute such fixes (vs having to fork) would make a big difference.
Could there be some process through which selected fixes from the community could be accepted? For example subjectively single out issues that clearly need fixing, come with reasonably straight-forward changes (pull request), and seem relatively low risk. This could further be coupled with additional specific requirements that such changes be tested and verified (vouched for) by at least 2 community members before they could be even considered. It gives the community a chance to step up.