Stop shading and relocating Java Websockets

[Protonull]

No description provided.

[Huskydog9988]

Does fabric support downloading libraries from maven central? If not I'm confused on how client's get their dependencies resolved.

[Protonull]

Couldn't find anything on https://wiki.fabricmc.net/ because god forbid open source projects document anything, but jar-in-jar (jij) dependencies are pretended as fabric mods, with a fabric.mod.json file generated for them, whose mod-id is generated based on its maven group and name. This then allows us to version-restrict the dependency in our fabric.mod.json as we could any other mod. And if there's two conflicting versions, Fabric will apparently load the newest version that's still valid under version-range restrictions.

[Huskydog9988]

So what determines where fabric will load jars from? Because I see nothing defining that. It is just locked to the central repo? If not why is this not used more for library mods like owo?

[Protonull]

The jars are contained within the mod jar, hence why it's called jar-in-jar.

[Protonull]

Don't get me wrong, I'm willing to revert this. I just found this page regarding "nested jars", which seems out of date given that it's for Fabric Loader 0.4.x and that it says "Nested JARs are not: meant to be used on non-mod Java libraries", yet this page (which links to the "nested jars" page and makes reference to Fabric Loader 0.11.1) says "Non-mod libraries can be repackaged as mods for nested JAR usage."

As mentioned in the merge-commit message (c33b739), this PR came about due to this conversation in FabricMC's Discord where I asked whether there's an equivalent to PaperMC's libraries feature. I was told there wasn't but that it needn't matter because the jar-in-jar (jij) system can reason about and choose which version of a conflicting library to use.

It's a trade-off though:

• Leaning into the jij system means relying on other mods to be configured correctly, something we cannot control. Someone else may have jij'd Java Websockets (iirc Nexum) but not put a version restriction in their fabric.mod.json. How that is handled is more or less black magic.

• Shading and relocating guarantees no conflict, but is something we have to maintain ourselves. And there is maintenance to do. Java Websockets for example has slf4j-api shaded into its jar. It may also prevent us from using more complex libraries: I was intending to add okhttp in the near future to move region downloads to server-sent events, a HTTP feature that's not supported yet by Java's built-in HTTP client. Except that okhttp is riddled with metadata files. I'm unsure how well, if at all, these can be relocated.

[Huskydog9988]

I was mostly curious as to the mechanism of how the library was provided to users is all. As for server-side push, I would not recommend it.

[Protonull]

As for server-side push, I would not recommend it.

Hmmm, looking at the linked announcement on that page, apparently server-sent events, while being described on wikipedia as a "server push technology", are nonetheless not effected by Chrome's removal. The browser compat section on MDN shows Chrome still supports SSE.

[Huskydog9988]

Not to get too deep into the weeds, but you could just have the client make a get request if you really want to moving fetching off of websockets. I'd argue it probably wouldn't save bandwidth or compute with fetching or pushing like that, but its only a guess.

[Protonull]

The reason why I'm looking to do this is that seemingly every mapping mod (as well as Minecraft itself) deals with chunks in the context of regions. Take VoxelMap for example where, each time a chunk is to be rendered, it attempts to load the region, apply the chunk data to it, and then flag it to be re-rendered. It makes sense then to do as many chunks for the region as possible within a single load-to-render process.

The problem is that MapSync's protocol is hilariously unspecific: there's no way to differentiate between a chunk received through live sharing, or through synchronisation. And there's no real way to resolve this without effectively reinventing a primitive form of HTTP requests... so why not just use HTTP requests? Well, I'm worried about data limits and timeouts.

While testing, each chunk tends to be ~4KB in size. And since regions are 32x32 chunks, that comes to ~4MB. That's not excessive... but still. That's a lot that can be requested from the server with a single request, one that is a non-stream so ALL the data needs to be provided for at once. Contrast this with server-sent events which would allow for various methods of staggering. For example, the server could split up the region data into rows, sending them in batches of events.

This is all hypothetical, I haven't actually used SSE before, but I think the idea has merit.