Switch from WebSockets.jl to HTTP.jl #500
Conversation
|
I started to look at the same issue as you, because I wanted to use the latest Pluto which uses HTTP 1 (the Pluto version compatible with WebIO is about six months out of date). I was failing at blink-tests.jl but after I added Blink to package manager, it's running now. |
|
The tests require https://github.com/JuliaGizmos/Blink.jl , which also uses WebSockets.jl, which is not compatible with the latest HTTP.jl 😥 |
|
Oof, I wanted to help out a bit with my recent experience porting to HTTP 1.0, but it looks like I won't have time to do the work to finish this PR. Someone else will need to finish it, maybe @olegshtch or @halleysfifthinc or @mind6 ? I gave you access to my fork. |
So everyone has to focus on updating Blink or the whole system will never move to HTTP 1? 😅 |
|
I think the quickest solution at this point would be to get WebSockets working with HTTP v1, which would fix compat issues with WebIO/Blink/WebSockets. I've started looking into it, but I have zero experience or knowledge of WebSockets or HTTP, so it will take me a while and possibly require more time than I can devote to it at the moment. |
It sounded like from the Websocket's page, the functionality is duplicated in HTTP 1, and development has stopped. |
|
I also believe that it is better to have dependents of WebSockets.jl switch to HTTP, because that means switching to a much more actively maintained and tested one. Porting WebSockets.jl to HTTP 1 would fix the dependency issues, but I think it might lead to similar issues in the future. The most sustainable way to spend our time is to help popular packages make the switch. |
|
I fully agree that having dependents of WebSockets switch to HTTP is the correct long term solution. However, upgrading WebSockets to work with HTTP@v1 has the benefit (assuming a non-breaking release) of fixing compat issues for existing releases of dependents. There appear to be 4 dependents of WebSockets that are not actively being developed (based on latest release more than a year old). These packages would be able to continue being used with a new version of WebSockets that is compatible with HTTP@v1. (Also these solutions are not mutually exclusive.) Latest release of WebSockets dependents:- [email protected], May 24 2022 - [email protected], Mar 23 2021 - [email protected], Dec 13, 2021 - [email protected], Oct 21, 2022 - GlobalSearchRegressionGUI.jl@v1, Nov 5 2019 - [email protected], Sep 21 2022 - [email protected], Dec 11 2021 - [email protected], Oct 13 2022 |
|
Mux dropped WebSockets dependency and use HTTP@v1. |
It could be easier to update Websockets. HTTP 1 drops some function handlers, what I did for Dash was duplicate part of HTTP 0.9's functionality and hide it in Dash itself. The PR on that is stuck on Julia being 1.5, so it can be a challenge to update nonactive packages. |
HTTP.jl recently had a big overhaul of the WebSockets code, and it is now very stable, and tested against the autobahn test suite. HTTP.jl also released 1.0, which means that we want the whole Julia ecosystem to make the upgrade. Right now, people are not able to update other packages that made the switch to HTTP 1.0, because they have WebIO in their (indirect) dependencies.
WebIO.jl currently uses WebSockets.jl, which depends on an old version of HTTP.jl. They recently changed the compat on
masterfor HTTP to include1, but without making compatibility changes, and the package now fails to import. In my view, the best way for dependents of WebSockets.jl to stay up-to-date is to switch to HTTP.jl, which is more stable, performant, actively maintained, etc.Because of #499, I was not able to run or test this code locally, so I need someone else to finish this PR. 💕
TODO
base_urloption. Is this supposed to be the hostname (127.0.0.1,0.0.0.0,localhost, etc), or a full URL (myapp.com/some/base/path/)? Right now, I assumed hostname.