Open zyxgad opened 3 years ago
If this is to be implemented, please keep the HTTP fetch option as a persistent choice. (i.e. don't deprecate/remove it). When deploying BlueMap at scale (for example, as an interactive component displaying a static world on a website) HTTP fetches are much better, as tools exist to optimize the delivery of static content over HTTP. These same tools do not exist for WebSockets
Do note that if websockets are going to be used, we'd also need to implement RFC 7692
in order to use some compression.
There is currently no intend to use web-sockets for the map-tiles .. in my opinion, http-requests are perfectly fine for that :) The web-sockets would be for live-updates like player-markers
Maybe instead of web socket, just use server side event ?
I will consider it, yes :)
With HTTP/3 becoming more common by the day, I'd say websockets wouldn't add much anymore.
The only thing I'd see websockets being useful for, is making things like player-locations be available in a more real-time fashion as mentioned in https://github.com/BlueMap-Minecraft/BlueMap/issues/244#issuecomment-968326350.
Pros
ack
packets (server assumes arrival, client will request packets when they go missing).Cons
I do not know how the internal webserver works from a code-perspective but I think the changes should be relatively minimal while still having a bigger impact than using websockets would have.
HTTP/3 is unlikely to be ever supported by BlueMap as it has been previously established that BlueMap won't support TLS by itself. To use HTTP/3 one should host the website with an external webserver such as nginx.
I would say using websockets for external live updates would be amazing. Maybe if hosted by the server it still does HTTP requests, but if you move external you have the option of using websockets instead of ajax requests for player positions.
I suggest bluemap use WebSocket to get data, that will reduce many unnecessary web request. Of course, bluemap need keep http API to compatible with the old client