In progress...

[EricForgy]

Trying to upgrade to HTTP v0.8, but it is not a small task.

[hustf]

This is appreciated, Eric, and I agree it's a big job.

It looks like you may have missed https://github.com/JuliaWeb/WebSockets.jl/issues/130. I dropped my initial try, and restarted it by first stripping down the package to what we are close to certain will remain here, i.e. commenting out the temporary ServerWS and ServerOption things. I am also quite fond of the logging functionality since I ended up writing something like it for every single application I made with websockets.

This way we can do a test-based stepwise conversion. The tests are also cut down to work with the reduced-size package. The next step for me would be to simply swith to HTTP 0.8, make this work, then un-comment more functionality.

So this would still be my approach, but if you are willing to put in most of the work, we'll go with exactly the approach you favour.

[hustf]

So, what I'm proposing is that we do the work in the established branch, and simply use the proposals you made here while rebuilding the package. For me, this is easier than trying to git-diff the two branches.

Also, it would save some work for you if you have wider access here. Would you want that?

[EricForgy]

Hi @hustf 👋

Yeah. I missed #130. I saw #120, but it seems that was already outdated (?), so just jumped in with both feet to work on HTTP v0.8.0 compatibility directly.

The last time I helped out with this package, my wish was to eventually merge the good stuff here with the good stuff in HTTP.Websockets and emerge with just a single package for using websockets. Unfortunately, it looks like that hasn't happend 🤔

I am coming back to this now because my package Figures.jl depends on HTTP.jl v0.8.0 and I want to use it with PlotlyJS.jl. PlotlyJS.jl depends indirectly on WebSockets.jl so it is impossible for me to use PlotlyJS.jl until this is sorted.

It may sound extreme, but I briefly discussed the idea of removing the dependency of Mux.jl and Blink.jl on WebSockets.jl and just use HTTP.WebSockets.jl instead. If that happens, I don't see a natural user for this package anymore and we should encourage everyone to just use HTTP.WebSockets.jl instead.

My suggestion would be to take the good stuff we like about WebSockets.jl, e.g. logging and tests, and move it to HTTP.WebSockets.jl. Then we can focus our limited resources on just a single package and make it the best possible. As it stands, I think both Mux.jl and Blink.jl depend on both HTTP.jl and WebSockets.jl so they are pulling in two incompatible websockets implementations, which doesn't seem ideal to me.

What do you think?

[hustf]

I think it's a good utilisation of resources to have small groups of people feeling strong responsibility for maintaining a reasonable size of code. One group of maintainers should not exceed four people. Http's codebase is much too large for most people that contribute voluntarily in their free time. Luckily, we have contributors that are much more dedicated, but that it usually over a shorter period.

I think the above is what weighs heavily with me. I also think the flexibility for experimentation in HTTP is very important, and hope that one day we'll have more parallelism. I suppose that means moving away from libuv. But for my own projects, I want a server running for days in a separate process somewhere, and that requires stability. Can't we have both? Won't stability and experimentation always be at odds no matter what we change?

[EricForgy]

Hi @hustf 👋

Keeping a separate WebSockets.jl is obviously fine. My biggest concern right now is just that my package is broken because WebSockets.jl does not support HTTP v0.8.0.

Rolling my package back to HTTP v0.7.1 is really not an option, so either WebSockets.jl needs to support HTTP v0.8.0 or PlotlyJS.jl needs to drop its indirect dependency on WebSockets.jl somehow. Either way is fine with me and I'm happy to try to help with PRs. My preference would be to get WebSockets.jl to support HTTP.jl v0.8.0.

I spent another few hours today trying to get WebSockets.jl to work with HTTP v0.8.0. Right now, the issue is that client_test.jl is not successfully starting the WS server 🤔

I think I just got the server started but its late here and I'm running out of steam so I just pushed what I have. If you don't beat me to it, I'm pretty sure I can get this to work tomorrow 🙏

Cheers 💤

[hustf]

Keep up the good work! I will want to somehow merge this step by step into branch issue130. Hope that reference is right from memory, currently on mobile.

[EricForgy]

Closing in favor of #137