Am confused by these two lines. Maybe it is just difference between the 'goal' and the 'current state'.
Goal:
"Compatibility: Supports the latest Minecraft server version and adheres to vanilla game mechanics. "
But NOT:
"Be a drop-in replacement for vanilla or other servers "
Will it be a replacement for Vanilla or not?
Drop-in replacement: refer to the ability of a server operator to simply exchange the current installation/executable of the server (be vanilla, paper, cuberite, etc...) for pumpkin while maintaining data, configuration, scripts and mods installed.
edit: grammar
If it is compatible, then can't I 'drop it in'.
They sound like they are saying the same thing.
It is compatible so clients can connect to the server and be fully operational, and thus, I should be able to drop in this server, and use it as a server?
How can it be compatible if it doesn't maintain data, configuration, etc..
Edit: or is this about Pumpkin files. Pumpkin will maintain it's own files, data, configuration. So it can't just use existing Minecraft data files.
So if it was a new world, Pumpkin would generate new pumpkin formatted files. But couldn't just 'drop it in' on an existing world and use the existing Minecraft data files.
Not sure of long term viability as far as effort, but if it is files, couldn't a converter from MineCraft to Pumpkin file structure, make the server 'drop in'?
* nginx is not a drop in replacement for apache
But from a client perspective, both implement HTTP/1.1.
* podman is not a drop in replacement for docker
But from a client perspective connecting to a service hosted in docker, that connection can still occur over TCP.
On the other hand:
* pkgconf is a drop in replacement for pkg-config
* cronie is a drop in replacement for vixie-cron
This seems too low level example to apply for Minecraft.
Minecraft has a lot going on, back and forth. For something to be 'compatible' it would need to be so detailed an implementation of the server, that it could potentially also be a 'drop in'.
If I were to interpret the statement made here I would assume that not-a-drop-in while being vanilla compliant means things like:
* It won't support server side mods without you re-writing them in rust
* It won't support bukkit plugins without you re-writing them in rust
* It doesn't support the configuration file format that the java server uses
* Maybe it doesn't support the world file format (which would be server side only)
* Maybe it doesn't support the same administrative commands (which you would only see as an administrator)
etc.
So it can definitely be compatible from the client perspective while being woefully incompatible with any prior experience anyone running a minecraft server might have.