Project Codex - Config / Settings API

[Axionize]

I'm starting a new "Project" system to track major features/refactors. The first one is Project Codex.

The Problem

Right now, Grim's config system is too tightly coupled to the underlying library (configuralize).

• It's hard for the Platform implementations (Bukkit/Fabric) to register their own settings files cleanly.
• Extensions basically can't register their own configs without hacks.
• If we ever want to switch config libraries (e.g. to Carbon) or support non-file sources (Redis/SQL), we'd have to break the API.

The Plan

I want to decouple the Data (the file/values) from the Loader (the logic).

I've drafted a new design using a Handler pattern. The goal is to let plugins register a source, and the manager figures out how to handle it. This keeps the API clean and lets us add support for things like Redis later or have extensions register sources without changing the API.

Proposed API

Here is what I'm thinking for the usage. Does this look annoying to use?

1. Registering a File (Standard usage)

// Extensions or Platforms just do this:
ConfigSource settings = ConfigSource.file("my-settings", new File(...), getClass());
GrimAPI.getConfigManager().registerSource(settings);

2. Custom Sources (Future proofing)
If someone wants to write a Redis loader later, they can register a handler that converts Redis data into a simple Map, and Grim handles the rest.

// Register logic for handling Redis sources
manager.registerHandler(RedisSource.class, (source, loader) -> {
    Map<String, Object> data = jedis.hgetAll(source.getKey());
    // "loadMap" is a new primitive that injects raw values into Grim
    loader.loadMap(source.getId(), data); 
});

Related Grim API Draft: GrimAnticheat/GrimAPI#17

I'm drafting the PR right now, but before I commit to this:

1. Is this over-engineered? Is the separation between ConfigSource (Data) and SourceHandler (Logic) too much, or do you think it's necessary for long-term support?
2. Naming: I'm calling them ConfigSource and ConfigManager. Is that clear enough?
3. Primitives: Currently, the API only accepts File or Map<String, Object> as inputs. Is there any use case where this wouldn't work?

Let me know what you think.