3tusk / kramh Goto Github PK

It comes into my mind after Darkhax from Diluv suggests to decouple the SMMART from Minecraft.

Time to drop a "M" from SMMART and rename the spec to SMART, "Schema for Mod Artifact Resource Tracking"

Currently the spec has two field that are tied to Minecraft, which are

• minecraft field in the artifact schema. It defines the Minecraft version that the given artifact relies on.
• framework field in the artifact schema. It defines the loader/API that the given artifact relies on, e.g. Bukkit, Fabric, Forge, Sponge, etc..

If we want to decouple it, this will become an element in the dependencies array. Something like [email protected]. Similar for the framework field, e.g. [email protected].
And this is where the problem kicks in: dependency semantics. Informally speaking, "dependency semantics" are interpretations and behaviors resulting from specifying some or no dependencies. Examples:

• If an artifact specifies a forge dependency, we know that this artifact can be used as a Forge mod. We can make similar interpretation if the dependency is fabric.
• If an artifact specifies a minecraft dependency… there are several things can happen.
  • The artifact is a jar mod. We have to go back to the dark age and manually extract files out and put into minecraft.jar. Old artifacts that are based on beta-1.x.x age may need such interpretation.
  • The artifact is a mod loader, or an API implementation. They may have all sorts of installation procedures, but generally you get a nice installer for this.
• If an artifact specifies no dependency… is that a standalone game?! Regardless, it can be useful if minecraft is also a dependency. We can also include minecraft into our catalog, and it is the base game, which apparently doesn't need to have specify dependencies at all. Unless you count Java as a dependency.
  • We can consider "virtual dependencies". More info will be in a separate issue ticket.

As such, as a spec for cataloging mod artifacts, we want:

• Investigate the possibility to somewhat formalize the "dependency semantics".
• With the help of "dependency semantics", decouple SMMART from Minecraft.

These are absolutely non-goals:

• Auto-install anything. This is left to anyone who is interested in "making a mod manager based on this spec".
• Make another Minecraft launcher. Same above, but minus the launcher part.

According to Darkhax from Diluv, they plan to use SHA512 to avoid hash collision, and thus uniquely identify a file (an "artifact", in SMMART terminology).

Currently, in SMMART, the artifact schema has several fields related to this:

• id in entry, which uniquely identify a mod entry in a certain catalog.
• version in artifact schema, which, combining with id, uniquely identify an artifact.
• checksum in artifact schema, used as a preliminary integrity check.

Darkhax's suggestion is to drop id because it is more or less Minecraft specific. Ideas to consider:

• The only constraint on id is uniqueness. The following SQL should explains my intentions:

  CREATE TABLE catalogs (
    id TEXT PRIMARY KEY
    -- other keys
  );
  CREATE TABLE artifacts (
    id TEXT,
    version TEXT,
    -- other keys
    PRIMARY KEY (id, version)
  );

  We can mandate that the id field does not necessarily imply "mod id" from Modded Minecraft world. We can, however, give some recommendations. For example, UUID.
• We can drop id in favor of fields in checksum.
  • IIRC the prototype implementation encounters trouble on checksum being an JSON object. Flattening that object should help.
  • Dropping id means that we have to use a long hash to index an artifact. Can we use similar approach featured in Docker container, where we can name a container while still being able to index it with hash? i.e. alias field.