This is an issue for discussing a potential mod configuration API. Welcome here is discussion on implementation, API, documentation and use cases for this API. Please let's behave, only constructive long-form discussion will be tolerated.

Player's idea for a configuration API: FabricMC/fabric-loader#77 (comment).

I would like to see a "configuration toolkit" based around this IR idea. It would be made of multiple low-level building blocks:

• The core part: the IR itself.
• A few IR manipulation functions such as upgrading an old IR and merging two IRs.
• IR <-> PacketByteBuf conversion.
• IR <-> String conversion for serialization. Possibly a generic config serializer API with one or two provided serializers.
• IR <-> Pojo conversion for modder convenience.

The modder would then be responsible for combining the various building blocks together as they see fit, and we could provide helpers for common use cases. For example, we could provide a helper to automatically sync some part of the configuration with users when they join the server, but this wouldn't need to be taken into account by the low-level API.

If we really want an IR that bad, we can just use data fixer upper's Dynamic. That is significantly lighter in weight than what's in FabricMC/fabric-loader#390 or #1336.

In addition, that draft above has horribly failed to address mod configs' most basic need: to toggle things easily. A beautiful tree api does not help much when what we want is a few key-value pair properties.

I don't think we want to be tied to DFU nonsense.

In addition, that draft above has horribly failed to address mod configs' most basic need: to toggle things easily. A beautiful tree api does not help much when what we want is a few key-value pair properties.

Don't worry, I'm pretty sure this is one of the attention points of a config API.
Having that said, I think we should minimize the number of layers of abstraction (cough DFU cough)... I would want the IR and the raw helpers to be quite simple and possibly a bit verbose, and then we can consider writing helpers.

I'd like to avoid DFU here, even though it provides an api to convert to an IR, the complexity of making a DynamicOps is very time consuming.

Minecraft has a library that is (partially and divisively) designed for configuration. If this API will try to sidestep that solution entirely, it's not useful to me. This API should at least provide the ability to use a codec as configuration.

In that case then a DynamicOps made to convert to/from our IR would seem fine to me.

imo that ir currently in that pr is worse than dfu. an ir should be simple to use as boolean getboolean etc.

Imo DFU is out of question. I don't understand it and I don't want to spend time trying to. A config API should be simple to use and understand, and be built on the minimum number of layers of abstraction, at most 1 for the IR and 1 for conversion between formats.

Imo we can keep the api simple. Java itself already suffices with the most basic java.util.Properties. Even though it's old, we can just design something simple as that than building some complex structure.

Also @Hephaestus-Dev since he opened that config api pr