Configuration handling

[asofold]

Similar to check data i assume that configurations for checks should also be handled with a central access point. Not necessarily used by all checks but offering some means of integration into some default config handling thing like world-specific configs, player-specific configs, configuration hierarchies (debug flags?).

Difficulties might be (amongst others):

• keep it independent of a certain server mod without adding too much bloat (if desired at all).
• allowing third plugins to add to the main config (no overwrite or loss of data due to missing or later-enabled components).

[asofold]

Actually this is merging two issues somehow, though "similar to check data" still somehow holds true.

We have the check configuration as on disk, with the problems to handle property getting and adding default entries to files - and we have the configuration objects used internally to store data for fast access by checks during runtime. With some justification one could depict the latter kind of configuration as data as well, but in any case we need a good modeling for this too.

So this issue should busy about the configuration file handling (and maybe creating configurations from files and how so during runtime).

[MyPictures]

Configuration is a big topic to talk and plan about.
Will we keep the actions as they are now or not?
Will we use yaml as before?
How should we handle multiworld stuff?
Are we going to aim for simplicity or stuff it full with booleans and integers to allow insane tweaking of checks and NoCheat?
How will we update it (auto)?
How will we check config version?

We could also have multiple configuration files so each check gets its own .yaml file but I guess having 30 different files might be a little annoying. On the other side it might also be easier to read and would cause less troubles with overriding also.

I like the idea of WorldName_configuration.yaml but it seems most users have trouble in understanding how to set this up. Maybe we could make it more simple...

[SuperSpyTX]

I only have 2 words to describe my idea: Dynamic Configuration.

I'd say an abstract configuration framework that would allow one to simply create an entire configuration file. I don't think YAML may be the best way to go due to the complexities of it.

However my idea revolves around the same caching system as YAML.

If we want to use the less overhead, we should consider a key=value configuration style, and having it cached via memory and a separate cache file. We could essentially create a configuration parser that could parse objects, and other things. We could have a readable configuration, and a cached configuration file. The cached configuration would "look like a bunch of garbage" (not obfuscated, but it'll be a bunch of mappings).

So standard configuration:

• Visually easier to read.
• Can be modified.
• Longer to process (?)
• All the unparsed data is in here.

Cached configuration:

• Harder to read.
• Can't be modified.
• Faster to process (?)
• All the parsed data is in here.

The configuration framework may not have to deal with cached configurations but as far as I'm concerned, having cached configuration can make /reloads much easier since there would be a hash check.

There might be a better approach, however.

[asofold]

We could also rely on some YAML library, though. Yet we really don't need and most likely don't want to use any complicated features like serialization, so we will be handling simple values and simple keys mostly. Even for that writing a parser might be more pain than fun (remember the history of Bukkit + YAML :p) - but after all we need an internal interfacing to the configuration whatever we put underneath...

Apart from the file formats and the internal interfacing the organization of "all the config stuff" is quite a big point here. I think the "one file fits all" is not as tasty anymore, i regard the worldname_config approach also as not 100% optimal.

So maybe we should detach from the file format for a moment and focus on how files are organized, what is in which file, how/if default values are added to which file.

We might like some of these, though it spreads the topic over quite some area:

• Have a very simplistic basic config file with all the simple switches but not too many details (touches actions processing, e.g. "have a kick action with a severity level that can be switched off with a global switch").
• Have world-specific configuration files, organized such that they can be easily recognized as such.
• Keep things simple for the user (adding defaults to world configs or not?).
• Consider splitting to individual checks configs, action configs, potentially other. "Expert settings" could have its own file. Imperative is to keep it easy to overview, though.
• A minimal internal config API could just deal out the paths to folder and files and probably parse the basic root config file which specifies what config format is used for the other ones - if no handler for the format is present ... bad luck :p. (tech issue: if checks are added by other plugins one might consider holding all registration until all factories are set up and the dependency and overriding hierarchy is somewhat complete, i.e. until post-enable.)
• It could also be interesting to provide a way to view / compare / edit / add defaults via in-game commands.

WorldGuard is using sub-folders for worlds and does not add defaults to the world specific config files. Giving the user the choice can be another way, though once added the defaults "pollute" the file and the user has to erase all now and then. Adding no defaults means that the user has to cope with all the indentation or copy and paste for the good of it - though here in-game commands to alter or compare configs can bridge the gap a little bit.

Then the splitting - should we make individual check configs? Should then general protection features be separated from check configs or is there a general config "protection" for that !? etc.

[SuperSpyTX]

I'd say for that, I'd go with the individual check category configs. This way you can transfer the check related files and such.

We should not have world related information in every config, only in the configs that are specified for the user to input. This way only the important information, such as moving related checks, are only recorded.

[asofold]

We will need to allow world-specific settings though - if we make sub folders for worlds or have file names or even config sections with moving@worldname: .... is up to us !

[asofold]

Double book-keeping would be strange ?

Say simplified entries like active-flags for every category + checks in the main config, then files for details ?
How does it sound to giving the user the option how to split into detailed files?

Probably per-category files would be the best trade-off for file-size and number of files.