A Discussion on Scope
dexman545 opened this issue ยท 3 comments
Recently, this came up again in the Discord, as it does periodically.
To centralize the discussion, and have the answer easily locatable by new users, here's an issue.
What should Fabric API contain?
This time, stuff about mod-interop was explicitly mentioned, so I will be focusing on that in this post, but this is more so a discussion, though not capturing everything that was was said.
FAPI is the one mod devs can simply assume users will have. Yes, not everyone will have it. Not every mod uses it, but most do, so this is a fairly safe assumption when you want inter-mod compat. This means that you can ensure your mod will be compatible with another without having to support several random APIs, or having an API support another API.
"We don't want to force people to use a system" is not a valid argument against this, as with anything with FAPI it is opt-in, though I agree with FAPI not defining systems ala Forge Energy where possible. Just having a common set of interfaces, like this example I made for energy, in FAPI would be enough for mods to talk to each other.
"We don't want to burden FAPI updates" is fine, but I think most people would rather trade some update speed for more utility. Though this is more down to personal preference. A separate, fabricmc owned API would be a nice compromise. It can be slower to update but include the interop mods need. Again, this would be opt-in. There's clearly a demand for this, and a lot of dev irritation around the lack thereof.
"If it's going to be a separate API, why not use a 3rd party one?"
Because it's another mod to make users install, or to JiJ. Not everyone needs all of FAPI, yet we still ship the fat jar. Having multiple libraries that al serve the same purpose exasperates this. Having it official also means you can assume other mods will use it, or at least be compatible if they so desired. It being official also aids in making it easier to find, and there would be more people willing to help maintain it rather than Bob's Feature API 3.
Fabric is no longer a random project it's creators never thought would be this big. A change of scope would also be valid.
Aside: The only place that seems to have the scope explicitly stated is the Fabric Wiki, which isn't a bad place for it, but should be in the readme here at the very least to limit confusion about what it does. A person wanting to make a tech mod would find an energy API fairly essential, so the current description isn't very clear, nor does it limit things only to vanilla context.
This is now documented in the contributing guidelines: https://github.com/FabricMC/fabric/blob/1.19.2/CONTRIBUTING.md#scope
Update speed isnt a big issue, if a module is broken beyond repair we can disable it and fix it later (think dimensions). There is nothing to say that there is a time limit on how fast fabric is updated, if the vanilla changes are so large it takes a long time so be it.
Fabric API's scope has loosly been:
-
A lot of mods require such feature for example the HUDRenderCallback even though its a trivial mixin. This can just be a common API to aid with mod compat.
-
Only one mod can implement the feature, long list of examples Registry Sync comes to mind first.
-
Its hard to impliment, and is best done correctally, a possible example if fluid rendering.
None of these things are set in stone, and none of them have a clear right or wrong awswer, some things are clearly in or out of scope, while other ideas need to be discussed. I think the best thing to do as a possible contribitor is make and issue and/or chat with people on discord to see if the idea is within scope.
